Calling os.exit with the "close" parameter set to true crashes the runtime since some uws handles are still active

[rdw-software]

While investigating the ASAN warnings for #356 I came across this problem:

When calling os.exit(code, true) the Lua state will be closed immediately, without "unassigning" the loop held by uws (in main.cpp). The result is a SEGFAULT (at least with ASAN enabled), while not closing the state leaks memory in the test runner.

[rdw-software]

Potential solutions:

• Make user handle uws cleanup (and possibly setup) - very inconvenient
• Hijack os.exit and make it perform the shutdown process automatically
• Rethink the shutdown sequence in general, it shouldn't have so many edge cases

Edit: Option two would be easiest, but Lua can't access the loop structure (so it'd have to be done in the C++ layer).

[rdw-software]

Approach 2 does work, but it isn't pretty... Requires a number of convoluted jumping-through-hoops:

1. The LuaVirtualMachine must interface directly with the uws_ffi bindings to unassign the loop
2. The loop struct must be stored in the Lua environment (I used lightuserdata), or the VM class itself
3. A new os.exit function has to be implemented in C++, to replace (wrap) the original Lua one
4. The "temporary" userdata global must be deleted (set to nil) to prevent LuaJIT from GCing it on shutdown

This adds a lot of complexity, relative to the actual usefulness of the code, and more stack manipulation than I prefer.

Potential improvements:

• The userdata could be stored in the uws package instead of a global UWS_EVENT_LOOP
• It might be simpler to overwrite the libuv/luv cleanup and handle the uws loop there?
• Alternatively, perhaps os.exit could be modified to just ignore the close parameter and "ignore" the problem (sketchy)?
• Maybe there's a way to use C++ features and have it handle all the resource cleanup (unlikely due to the underlying C APIs)?

Current prototype is here - will have to think about it some more as I'd prefer a simpler workaround if possible...

[rdw-software]

Actually, it doesn't look like the solution always works: In some cases (TBD) there are active handles still, but not sure why.

Can\t reliably reproduce, but there are handles being processed in luv (other than the ones spawned by uws) that may be the culprit. Unrelated? Let's see what the CI says, maybe the issues does crop up again, or perhaps it's a separate issue.