Adds load balancing to connection pool

[bompus]

Related to #213

Load balance our pool connections, sending next workItem to connection with least number of already-pending workItems. Eliminates need for connectionIndex.

[owenallenaz]

I totally support this. A long, long time ago, I remember we tried to alter the pool so that instead of pushing to connection, we queued the tasks up into an array, and then when a query finished, the worker would pull the next work job off the queue, that way it wouldn't matter if you had slow or fast items in the work queue, since as soon as a worker finished, it would grab the next job available. When we proposed that change a while ago it was just before they did their big rewrite a year or two ago to the pool and it kinda disappeared since they weren't interested in merging a change like that into a dying code pathway. Is a queue like that at all possible with their current architecture or is it just too technically complicated. If it's too tricky, then this is a great interim solution.

[bompus]

@owenallenaz They are planning on rewriting the pool logic to match a unified spec across drivers. If you read https://github.com/mongodb/specifications/blob/master/source/connection-monitoring-and-pooling/connection-monitoring-and-pooling.rst#waitqueue , it seems to be very close, if not identical, to what you described as the ideal scenario, with connections pulling an item from a single WaitQueue as they become available. If that is indeed the case, this PR serves no purpose after a single WaitQueue is implemented as I read the spec.