Adding PR again as my previous PR #60 was not processed due to OCA - which is now sorted out.

There is deadlock bug in MySqlPoolManager.cs. It makes the library unusable in any .Net applications with SynchronizationCotnext while using pooling feature.

It causes a deadlock of threads, application will hang forever. Affected are:

• ASP .NET MVC app (on full .net framework),
• Windows Forms App,
• WPF app.
  If using Pooling=true in connection string (common scenario).

What is more, it leads to breaking the whole appPool on IIS (for ASP .NET MVC app) as all threads from thread pool will eventually deadlock.

This looks like obvious human error, there is missing ConfigureAwait(false) when awaiting on semaphore. Note that the ConfigureAwait(false) is widely used in all other places at this class but in this one is simply missing.

await waitHandle.WaitAsync(CancellationToken.None);

In this PR:

• Two places in MySqlPoolManager.cs are fixed to not cause deadlock
• Changelog and library version updated (I hope this critical bugfix will reach all users sooner than later)
• Unit test which allows to reproduce the issue (for the sake of simplicity I included only one of the SynchronizationContext scenario to demonstrate deadlock).

How bug was introduced

1. On 11 Jan 2023 there was change from using lock to SemaphoreSlim in MySqlPoolManager.GetPoolAsync. Unfortunatelly this introduced a bug - the new Semaphore was created every time method is invoked so there was no threadsaffenes at all.
2. The bug from 1. was fixed by setting the semaphore static so the thread safeness was introduced again. Unfortunately acquiring the lock on semaphore is done asynchronously without using ConfigureAwait(false) so it causes deadlocks in described in this PR scenarios.