V8 teardown crash: order-of-destruction between JS context and Napi::Env

[syntheticmagus]

It appears to be part of the contract of N-API objects (notably ObjectWraps) that they strictly cannot outlive the Env that created them. This creates the curious scenario where, in canonical settings where the N-API abstraction "owns" the JS, the actual Env itself must be created after the JS is created (because it takes a reference to the JS as a parameter), but it must be destroyed after the JS is destroyed, breaking symmetry. The reason this becomes a problem is because the N-API objects owned by the JS try to use the Env that created them while destroying themselves, which they cannot do if the Env has already been deleted. The effects of this bug are currently hidden on Chakra by the JS context shutdown problem referred to in #94, and hidden again by #142 if Chakra is shut down correctly. However, because the former problem doesn't affect V8 and it currently seems tear down types in reverse creation order (By contract? Coincidence?), V8 encounters this error and consequently crashes both on shutdown and on refresh.

This problem gets a bit weirder when we take into account situations (like React Native integration) where the JS runtime can outlive the Env by an indefinite margin, and there may even be occasion to create a new Env after an earlier one was discarded. With all this in mind, do we need some way to control the lifecycle of all N-API objects, perhaps tying them directly to the Env that created them so that they are automatically torn down when it is? Is there another way to deal with this problem?

[syntheticmagus]

Note: as of #144, V8 is now able to correctly shut down again; the problematic references were actually coming from the Dispatcher and Task, not from JavaScript. That fix just gets us out of a broken state, however, and most of the questions about order of destruction still need further investigation.

[bghgary]

Fixed with #157