removes queries on the go so they don't get stuck on exceptions

[blizzz]

When one query fails with an exception, the queue is not cleared, because ClientRequest::executeQuery() is left earlier. Thus, using the context again will always trigger this query (and also already run queries), and will always fail.

Simplified use case:

1. Fetch File A from SharePoint
2. Try to fetch not existing File B from SharePoint, catch the Exception it as it is an valid outcome
3. Any other requests from within the same context will fail, because this query is not removed.
4. Recreate a new context (null the old one)
5. Trigger an action on File A (e.g. recycle())
6. → Fails, because File A is bound to the old context
7. → Fails also with getContext() on File A, because of 3.

Three possible solutions:
a) remove the faulty request before throwing the Exception
b) remove the current query unconditionally
c) offer a way to clean up registered queries.

I implemented b in this PR, because it sounds most reasonable for me. Way a) would leave earlier queries in the queue, while way c) would let to a lot of unnecessary handling which is being done in one place now.

@vgrem Or have the queries been kept in place for some reason?

The alternative of having a context for each file or folder object is rather nightmarish.

[blizzz]

@vgrem I am a bit puzzled about the failing tests. They happened on against 5.4 only, but not against HHVM. Could it be some "temporary" issue (= could you restart the tests?)? Also since the errors originate from parsing, and my changes do not affect this. Unfortunately I do not have a setup that would allow me to run the affected test files successfully 🙊 .

I revised the code couple times but missed to find a scenario here a misbehavior could be triggered. Also the $queries array is protected, cannot be modified from outside (except via addQuery). Also the failing tests seem to be just too simple and common.

[vgrem]

@blizzz , indeed, it puzzled me as well.
All right, let me restart the tests and if it will persist, then will try to reproduce it locally.

[blizzz]

Still the same. And still odd. The trigger should be that $response is somewhat different to what is expected, that's my conclusion. The pre-condition (e.g. testCreateMyContact()) is working, otherwise we had more failing tests. Thus also the $qry parameter should be alright; and doing some experiments on 3v4l.org doesn't not tell me anything unexpected over any PHP version.

I'll do another dummy PR with a comment change to verify that master succeeds…

Other than that thanks for looking into it :)

[blizzz]

There PeopleManagerTest::testFollow also fails, but the errors don't. 😕