refactor: Get rid of the legacy quiescence control stuff

[mykola-mokhnach]

BREAKING CHANGE: the minimum supported Xcode SDK version is bumped to 10.2
BREAKING CHANGE: quiescence check is enabled by default (only breaking for WDA, because Appium does enable it by default)

This is a big change and it needs to be carefully tested on supported SDKs before being merged to master. Long story short, now the actual quiescence timeout is controlled by waitForIdleTimeout setting (same as in uia2, also measured is ms). Setting it to zero disables quiescence checks. The default value is 10 seconds (same as for Android).

@Dan-Maor @KazuCocoa I hope you could assist with testing

[KazuCocoa]

okay, will take a look. (It seems this should be after 1.19.0)

[Dan-Maor]

This may help to fix the testClickAlertButton test: in fb_resolveWithError, use:
- (void)resolve:(NSError**)arg1;
instead of:
- (void)resolve;
That way the resulting resolve error of the nonexisting alert element will not trigger an assertion failure, it will only be dumped into the error variable.
I have verified that testClickAlertButton passes locally with Xcode 10.2 when using this selector instead, however I did not run any further tests yet.

[mykola-mokhnach]

Thanks a lot @Dan-Maor , I've applied the patch

[mykola-mokhnach]

@Dan-Maor I've tuned the logic a bit and swizzled lower level methods named _notifyWhenMainRunLoopIsIdle: and _notifyWhenAnimationsAreIdle:. This approach should be more unified, since the methods are also called at application startup for quiescence check. I'm not quite sure about the incoming arguments of their callback blocks. While debugging it looks like they both contain nil

[Dan-Maor]

I think swizzling this deep might be a bit risky.

One thing I noticed was that the second argument of the callback is not an NSObject of any kind, it rather appears to be a pointer to something which I couldn't identify as of yet (need to look further into it, currently occupied with work tasks). As it's currently defined as id, WDA crashes if it's not nil. This is a scenario I was able to get to after some testing with simulating a slow app launch by lowering the waitForIdleTimeout. After modifying the second callback argument to (void*) WDA did not crash, however it did hang in createSession of the Clock application for a long time.

I'm afraid that the more we test we'll find more scenarios like the one outlined above. Therefore I really think we should stick to the internal XCTApplicationStateTimeout() (which holds 60.0 by default) and XCTSetApplicationStateTimeout(double timeout) functions and let the XCTest framework handle it for us.

[dmissmann]

We apparently know what the signature of those blocks is: void (^)(id, NSError *). Casting the IMP pointer would still be necessary in XCUIApplicationProcess+FBQuiescence.m, but we would have the same things defined in both places.

[mykola-mokhnach]

changed the signature

[dmissmann]

There's still a race condition because isSignalSet can be changed on a different thread.
Could we just use dispatch_once in both places where onIdle(...) is called and get rid of isSignalSet?

[mykola-mokhnach]

added locks

[dmissmann]

Same here as above in swizzledNotifyWhenMainRunLoopIsIdle

[mykola-mokhnach]

added locks

[dmissmann]

Is the original callback also being executed on a background thread?

[mykola-mokhnach]

yes, it should be always executed on a background thread