Edited 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).