Client operations over SSL will always fail in version 1.2.0 if the client is from a mongoc_pool_t.

Beginning in 1.2.0, clients from a pool all share a set of sockets for server monitoring, but use distinct per-client sockets for application operations (such as queries, writes, etc.). When the pool creates sockets for monitoring, it begins a non-blocking connect on each and uses "poll" to wait asynchronously for all of them to finish connecting. When an individual client creates a socket for application operations, the client connects the socket synchronously.

In the process of a series of refactorings (mainly related to CDRIVER-894) we introduced a new internal function mongoc_stream_wait that a pooled client uses to await connection on a socket before doing application operations on it. We didn't re-test SSL connections in pooled mode after those refactorings were completed.

This allowed a bug to slip through: the new mongoc_stream_wait calls mongoc_stream_poll on a buffered TLS stream, but buffered TLS streams don't implement "poll". So mongoc_stream_poll always errors ("invalid argument", EINVAL) and the connection is considered failed.

Symptom: a "find" and "mongoc_cursor_next" operation with a pooled client and SSL enabled fails, with the error, "Cursor Failure: Failed to connect to target host".