CSHARP-2423 Fixed Connection Pools lock contention

[valentin-abalmasov]

Locks changed to lock-free containers in order to get rid of lock contention in "threads heavy" environments. JIRA issue The main problem in existing code that all releases (Dispose) of connections inside pools was made inside lock. It is possible to rewrite existing code and move Dispose outside of the lock, but lock-free containers are far more effective that current solution

[medboz]

@valentin-abalmasov did you found a solution for you lock contention issue, We have the same issue with MongoDb.Driver 2.18.0 ? I see that related jira ticket is closed

[valentin-abalmasov]

@valentin-abalmasov did you found a solution for you lock contention issue, We have the same issue with MongoDb.Driver 2.18.0 ? I see that related jira ticket is closed

@medboz Unfortunately our fix was not accepted as merge request, but, we do apply the changes from merge request to our own fork of driver, because we still experience "lock contention" issue in our software

[BorisDog]

Thanks for your PR @valentin-abalmasov. ConnectionPool synchronization behavior and event order is largely dictated by our specs, and this can be a breaking change in some scenarios. gRPC will replace our existing connection pooling logic. How we integrate this with our current networking code is uncertain at the moment as we will have to maintain both the mongorpc and gRPC stacks in our drivers for many years. That said, I don't think we will get around to reworking the connection pool locking code before the gRPC work and we can close this as "won't do".