Do not leak running pools from the internal collection

[joerg1985]

Context

In theory the ThreadPoolManager could leak running thread pools an create new ones.
I have not seen this in the wild, but it could happen.

The ThreadPoolManager did use a WeakHashMap<String, ExecutorService> to store the running pools.
It holds a weak reference to the String and a strong to the ExecutorService.
As soon as the String gets collected by the GC, the strong reference to the ExecutorService is dopped.

This is a example of problematic code, this could create two pools when GC did clear the WeakReferences between the two calls to ThreadPoolManager.getScheduledPoolUnwrapped:

ThreadPoolManager.getScheduledPoolUnwrapped("test" + 1);
System.gc();
ThreadPoolManager.getScheduledPoolUnwrapped("test" + 1);

Beside this, there are other issues like accessing the WeakHashMap outside a synchronized block.
This double check logic used is in my mind only safe for immutable objects...

Description

This PR will replace the WeakHashMap with a ConcurrentHashMap to fix the issues above.

[kaikreuzer]

Thanks for this fix!
It feels as if the use of WeakHashMap didn't make any sense here in the first place, right? I assume the thinking was rather that the value is a week reference and that the entry should be removed from the map in case that the pool is not used anywhere anymore. But having weak references to String keys is just wrong.