Commented Issue: memory leak in http_client (probably concurrency logic) [14]

I can't pin point the exact code but based on std::async there might be leak in the thread pool.
You can see that in the following logic std::async leaks (not sure when threads will be released).

```
void test(){}

void async_leak(int loopCount)
{
for(int i = 0; i< loopCount; i++)
{
auto fut = async(launch::async, [](){test();});
fut.get();
}
}
void thread_leak(int loopCount)
{
for(int i = 0; i< loopCount; i++)
{
thread t1([](){test();});
t1.join();
}
}

void http_client_leak(int loopCount)
{
for(int i = 0; i< loopCount; i++)
{
http_client client(U("http://www.google.com"));
http_response r = client.request(methods::GET,U("/")).wait();
}
}
```
http_client "leaks" less than std::async but more than std::thread:

if you do 1000 iteration:
From 1 thread to 13 threads
From 13 to 143 handles


You may argue that it's normal but how do we mitigate this kind of "leak" so it doesn't become a problem? Is there a way to configure the thread pool size and scheduling on http_client or http_response? There is no way to force release the thread pool I assume so we are basically letting the system decide when it should be releases (if it does).

This is guaranteed to be flagged as memory leak by app verifier (any test done with that against Casablanca?) I see leak from my test so part of the issue is this and also std::async (moving away from that for me). If I have X number of permanent threads throughout a process' life spawn that's acceptable as long I can control that number (then this becomes the baseline otherwise it's not possible to justify the behavior to QA).
Comments: Yes, we run Casablanca through a bunch of tools before release, including AppVerifier, and haven't seen this issue before. It's hard to know what to expect from a thread pool -- creating threads is so expensive, that once one has been created, it's a good idea to hang onto it, and the thread pool usually does just that. Seeing dozens of threads on a 64-bit system when running on the thread pool is not unusual. If there was more data on this, it would help us look at what the issue is here. That there are 13 threads after 1000 iterations doesn't tell us enough -- what is the behavior as you keep running for a few minutes? What does the curve look like as you extend this to 10K, 100K, 1000K iterations? Niklas