Making crossplat::threadpool::shared_instance() safe to use in cpprest DLL

[garethsb]

This took me a while to track down. While investigating PR #608, on Windows / VS 2013, I found that many of the test suites would more often than not complete successfully, but then the test_runner exe wouldn't exit. I found this was due to deadlock while the test_module_loader was unloading DLLs. The culprit is the destruction of the static threadpool_impl inside crossplat::threadpool::shared_instance(). Its destructor must join all the threads in the pool. This is likely to deadlock because in DllMain at DLL_PROCESS_DETACH, the loader lock is held, and the thread to be joined therefore cannot signal thread termination by DLL_THREAD_DETACH. (A quick web search finds many explanations of this, including some good ones on Microsoft's own The Old New Thing.)

Why hasn't this been reported before? I assume mostly on Windows, people aren't using e.g. CPPREST_FORCE_HTTP_LISTENER_ASIO or if they are, they aren't explicitly unloading the cpprest DLL until process termination.

There are two approaches to fixing this:

1. Don't expose a shared instance via the current API. A reference-counted interface, e.g. exposing shared_ptr<threadpool>, could work.
2. Keep the API. Jump through hoops internally to ensure we can't deadlock in the destruction of the static instance.

Assuming 2 is preferable, I ultimately discovered that asio already provides the mechanism to solve this exact issue. And it has been present and documented in asio since at least Boost 1.37.0, so although it is in the namespace boost::asio::detail I think it can be relied on. I have tried Boost 1.65.1 (current) and Boost 1.54.0 (cpprestsdk's documented minimum version). I have run tests on both Windows and Linux platforms.

Implementation notes:

• I'd have kept the #if defined(CPPREST_PTHREADS) alternative, but boost::asio::detail::thread picks Windows threads or POSIX threads (or falls back to std::thread) appropriately anyway, so the code is now mostly simpler than it was too.
• I'd have used std::vector<boost::asio::detail::thread>, but for some reason the thread type isn't movable, hence the use of std::unique_ptr.

[msftclas]

All CLA requirements met.

[ras0219-msft]

Thank you for the PR and the detailed writeup! I have to concede as well that using boost::asio::detail::thread is the current optimal solution here. I do wish we could reduce dependency on boost over time, but it doesn't look like the case here :)

I've removed the restriction to only follow this process in DLLs, because it's unfortunately common for people to link things built as static libs into DLLs. It shouldn't harm EXEs either, so it seems clear that we should just always use this new path.