I'm working on flattening the socket pool (issue 472729).  The idea is that instead of laying socket pools, we're layer ConnectJobs, and just have a single socket pool with different types of ConnectJobs in it (Initially, we'll use callbacks instead of SocketParams, but may change that eventually).

This will create a bit of a problem with WebSockets, which use their own ConnectJob class on the bottom of the stack, but the normal ones elsewhere.  The simplest thing to do seems to be to merge TransportConnectJob with WebSocketTransportConnectJob, which isn't too different.  Then can just add a bool / enum class to TransportConnectJob indicating if it's a WebSocketConnectJob, and we're good to go.  The differences are small enough that we can just obtain the WebSocket locks if it's a WebSocket, and otherwise, do the same thing on both paths.

We'll also need to update WebSocketTransportConnectJob to be a single flat socket pool in the same way we're modifying ClientSocketPool, but as almost all of the changes there are on the consumer side, that should actually be pretty trivial to do (Though it will slightly change WebsocketTransportClientSocketPool semantics - stalled_request_map_, for instance, will include sockets stalled on SSL negotiation and proxy tunnel establishment, not just establishing a connection).

Conveniently, this will also eventually fix issue 916690.

[ricea]:  Do you see any problems with this?  The full design document is at https://docs.google.com/document/d/1g0EA4iDqaDhNXA_mq-YK3SlSX-xRkoKvZetAQqdRrxM/edit, though I hadn't realized how different websockets were at the time, but I think they'll really be a non-issue.