Use separate internal thread pool for handling messages about hazelcast-csharp-client

[stalek71]

The thread from ThreadPool used by HZ client lib for message handling (encoding/decoding) is used only for really short time (it uses Task so the flow is based on "continuations"). If there are any Wait() operations blocking current thread they should be removed and converted to "continuations".
In case the user exhausted ThreadPool resources (threads) the problem will be serious also for user application (not for HZ client lib only). By me .Net framework management of ThreadPool is optimal in such cases and this issue can be closed.

[stalek71]

@cangencer , @asimarslan ?
Should I close this issue?

[asimarslan]

I think we should keep it open as @cangencer's initial offer is still true. We should avoid internal usage of default threadPool.
see #224

[zpqrtbnk]

We are about to release version 4.0 of the Hazelcast.Net client, and the code has been vastly refactored, rendering this issue... more or less irrelevant. We do use the default .NET thread pool at the moment, but because we run fully async, we do not block one thread per "task". If a user launches a large number of "tasks", they'll be managed by the async mechanism and use the available threads when needed. Just like most MS code uses the default thread pool.

In case the user manages to bring a machine down because of too many "tasks", replacing the thread pool would not fix the issue. We'd have to revisit the tasks scheduler to limit concurrent execution of tasks, putting back-pressure on the user.