CXX-336 remove connection pool and associated cruft

[amidvidy]

includes a small number of trailing whitespace removal noise, but given the pretty large changes to the files involved, I think its acceptable

[amidvidy]

this comment should probably stay.

[acmorrow]

Adam overall this looks good. I have one general comment and two high level concerns:

• RE whitespace only changes, don't go back and revert those (unless very easy to do so, for all of them), but in the future resist the temptation, since it confuses things like git blame. If possible, do them in separate commits if you think they are warranted. In general, I don't think they are worth going back and fixing, though of course we should be ruthless about not allowing new ones to be introduced.
• We are now requiring users of the library who want pooling to implement it themselves. This is fine and I think in general it is the right thing to do. However, I'd like to ensure that it is actually possible for them to do so. In particular: did the previous pool implementation utilize any non-public information about connections that would preclude a user of the library from re-creating the previous pool behavior? Can you provide an argument about whether or not this is possible post this change?
• I'm somewhat concerned about the cost of creating new connections in the regime of expensive auth mechanisms like SCRAM. Can you make an argument about how a user of the library will be affected by expensive authorization mechanisms with the pool removed? In particular, I'm interested in the cost of connections internal to the library, since assuming that the resolution of the above point is satisfactory a client of the library could obviate the auth cost by building their own pool. However, there is nothing they can do about connections being constructed internally by the library.

[amidvidy]

re: whitespace changes, I think I'm just going to bite the bullet and undo them

I don't think it should be hard to implement a pool. The DBClient supplies a public sStillConnected() method to check if a connection is still up. The rest of the work required is just constructing a threadsafe mapping of HostAndPort to List/Stack of DBClientConnection objects, which is still entirely doable.

Regarding cost of creating/destroying connections, this is definitely a concern. The ReplicaSetMonitor relies on the pool to cheaply contact monitored hosts in RSM::Refresher::_refreshUntilMatches. With SCRAM this could be overly expensive. I think a stopgap would be to implement a pared down pool, private to the ReplicaSetMonitor and make ScopedDbConnection completely internal to the library. I will try to rework this PR in that direction.

[amidvidy]

So I added a connection caching mechanism to ReplicaSetMonitor. It's pretty simple and should amortize the cost of frequently executing isMaster on RS members while refreshing RS state. It also serves as a simple example of how an end-user of the driver could implement a pool since it uses no non-public methods of DBClientConnection.

[acmorrow]

Where did this uassert code come from?

[amidvidy]

done, just going to use 0.

[acmorrow]

This is looking good. I want to chat about the conn cache a little bit and maybe do one more round: I think it may be able to be simplified somewhat

[amidvidy]

removed whitespace changes, cleaned up conn cache, and removed unnecessary null checks. @acmorrow let me know what you think.

[acmorrow]

Don't think this comment is true anymore.

[amidvidy]

whoops, fixed.

[acmorrow]

LGTM. Ship it!

[amidvidy]

sweet.