Genycloud teardown

[d4vidi]

Description

Another (mandatory) step towards support for Genymotion's SaaS solution (see #2429): supporting tear-down.

One of the most important aspects of using cloud emulators is the proper management of their deletion (in particular, because pricing is usage-time based). This change introduces instances deletion that in a Jest-based environment, is based on the global-teardown hook, with the API invocation looking pretty much like this:

// global-teardown.js
async function globalTeardown() {
  const detox = require('detox');
  await detox.globalCleanup();
}
module.exports = globalTeardown;

Namely, such that the internal details of the shutdown are obscure from the Detox user's perspective, and are available through an API that feels natural.

In Mocha - or any other test runner that does not support parallel-execution, this can be integrated by dispatching detox.globalCleanup() immediately after detox.cleanup(). In due time, we will add this to our Documentation and scaffolding scripts.

Underneath, what happens in a nutshell is this:

1. A new, custom device-registry is initialized (on top the existing ones), which never clears its content throughout the execution.
2. Each driver spinning up a new cloud instance in it's init, adds the associated uuid to the device-registry.
3. Eventually, through global-teardown (at global context), the Genymotion driver statically reads the registry, issues and executes deletion operations in a Promise.all() fashion.
4. The end.

Important: This technique is quite robust and may seem elegant, but it's important to keep in mind that it is nevertheless not ideal. Being charged by the minute, ideally, we would like to delete each instance once its worker finishes the last bits of its work. I've experimented ways of implementing this by registering a process.on('beforeExit', () => {...}). While it simplified the implementation a great deal, it didn't work, for two reasons:

1. Jest seems to hold workers up and running right until the very bitter end (global teardown), so the callback isn't called earlier than with the current approach.
2. Jest doesn't approve of asynchronous work inside each worker as it waits for it to be killed: it warns the user with the famous open handles log, and sometimes force-kills before the beforeExit callback completes.
   As a bottom line, then, in order to introduce the ideal optimization, we would have to push this into Jest itself (see here).

Last but not least, this also adds support for driver.shutdown(), such that genymotion-cloud testing would respect Detox' --cleanup argument.

[d4vidi]

@noomorph if you have any better suggestions as to how to provide this in a cleaner way (leaving the TODO note aside, however), I'd be happy to hear them.

[rotemmiz]

Maybe we could add a link to the instance's web GUI, so it would be easy to open and examine it.
Also, it might be a good idea to add that link when a cloud emulator spins up.

[d4vidi]

Yes, I will do both!

[rotemmiz]

What is reverse-linear polling? backoff strategy?

[d4vidi]

Exactly

[d4vidi]

@noomorph please review post-factum, along with #2466. Although I'm still not done with all of the comments from the first PR (#2446), I will get to everything, eventually.