startup is not very interruptible (fRequestShutdown) #8064

This mostly only matters when testing, but it takes a long time for Ctrl+C to interrupt anything during initial startup because fRequestShutdown isn't checked much. (Also, fRequestShutdown is currently accessed across threads without synchronization.) We could put in more fRequestShutdown checks but init calls into some long-running main functions that already check for shutdown via boost's interrupt mechanism; a consistent solution would be preferable.

One approach would be to put everything in boost threads and use boost interruption everywhere (main could join the WaitForShutdown thread rather than calling it in main's thread). AppInit2 doesn't expect interruption and would need modifications to handle that exit path correctly, but the interruption points that already exist in the main code would make startup much more abortable. The consistency with the rest of the code would also be a plus and would allow a better implementation of #8063 that isn't practical with fRequestShutdown.

Startup is reasonably interruptible, compared to where we came from. Sure, some phases can still take a while but it used to be much worse.

Also, fRequestShutdown is currently accessed across threads without synchronization.

It's a boolean, volatile, and a special signal atomic type. As it is not allowed to lock within a signal handler, this should be enough:

volatile sig_atomic_t fRequestShutdown = false;