Make lock-related tests not flaky

[marcin-krystianc]

Fixes #210

After many experiments, I've finally found that flaky lock-related tests were caused by a low initial value of worker threads in the thread pool. It led to deadlock-like scenarios which resulted in expiring sessions due to missed renewal window.

[mfkl]

Wow, interesting find... I see that you used GetMinThreads before but decided on using 32, 4 in the end. Why is that? Would this risk breaking silently when they change the runners?

Good job!

[marcin-krystianc]

I see that you used GetMinThreads before but decided on using 32, 4 in the end. Why is that?

Well, GetMinThreads was only for debugging purposes, wanted to make sure that my theory is true.
When we override these values with SetMinThreads there is no need to call GetMinThreads anymore.
It seems that xUnit sets the number of worker threads equal to the number of CPU cores and GH runners have only 2 cores (or 3 cores for MacOS). Also, the test failures happened only for the net461 target, apparently .NET Core can quickly add new threads to the pool whereas .NET Framework is unable to do it quickly enough.

PS:
Also, worth mentioning this blog post which was really helpful: https://andrewlock.net/tracking-down-a-hanging-xunit-test-in-ci-building-a-custom-test-framework/.

[marcin-krystianc]

FYI, I've checked how many threads are initially created by console applications and it turns out that number is also equal to the number of logical cores. So to avoid creating "too many" threads in the thread pool I've just pushed a change that bumps the number of worker threads only if the initial number is less than 4.