ASIO issues with uWS::Loop falling through with multiple Loops/threads

I've explored a bit more after briefly filing before, and found there are (what seem to be) a few issues with ASIO as a backend (hopefully fixed one of them).

I'm happy to split this into separate bugs, but it may also be fairly related, and am looking for advice on what to dig into to try to resolve it. The issues:

• If I have two different threads, and each calls uWS::App::Run, the Run will not finish on either of the the threads, until us_listen_socket_close is called on both.
  • This can be seen when TRIGGER_BOTH_APP_CLOSURES_BEFORE_BLOCKING_ON_EITHER is set to false in the repro case
• Even with no handlers set up or used for uWS::App (i.e. nothing except the default timers going on), it waits 1 second before exiting after us_listen_socket_close. I can work around this to shutdown more quickly (which matters since I'm doing this several times in a test) - by calling us_timer_set with a faux 1ms timer. I assume there might be an easy proper fix, I just don't grok enough of what's going on yet.
  • This can be observed in the repro case by setting TRIGGER_BOTH_APP_CLOSURES_BEFORE_BLOCKING_ON_EITHER to true (avoids the first issue), and ACCELERATE_SHUTDOWN_WITH_FAUX_TIMER to false.
• Sometimes the uWS::App::Run never falls through, when, in a loop, creating two threads and calling uWS::App::Run and then exiting with us_listen_socket_close. If I run it 500 times, I rarely ever succeed on all of them.
  • This can be seen with TRIGGER_BOTH_APP_CLOSURES_BEFORE_BLOCKING_ON_EITHER set to true, and ACCELERATE_SHUTDOWN_WITH_FAUX_TIMER set to true.

This is the repo case. Happy to investigate further, though a couple of suggestions of where to look will speed me up.

Start by compiling and repeatedly running the supplied uwebsockets_many_apps.cc reproduction, varying TRIGGER_BOTH_APP_CLOSURES_BEFORE_BLOCKING_ON_EITHER and ACCELERATE_SHUTDOWN_WITH_FAUX_TIMER. Trace uWS::App::Run, us_listen_socket_close, and the ASIO backend across both threads. Done means the reported blocking, one-second delay, and intermittent non-returning shutdowns are reproduced, explained, and covered by a reliable regression test.