fix(tls): potential deadlock in StdSocket::poll_ready()

[abonander]

Does your PR solve an issue?

Changes StdSocket::poll_ready() to schedule wakeups for both reads and writes where applicable, and return if either direction is ready, not necessarily both.

Previously, if the TLS code, e.g. rustls::Connection::complete_io() tried to both read and write on the socket, poll_ready() would wait for the connection to be ready in both directions. This was prone to deadlocking if the server-side was waiting to receive more data before it sent any, e.g. it was waiting for us to write a full Execute packet so it could start executing a query and feeding back results.

poll_ready() now returns Ready if either direction is ready even if the other direction is blocked, letting the TLS implementation do as much I/O as possible before going to sleep and hopefully preventing deadlocks of this kind.

fixes #4248

This likely fixes a number of other hang/deadlock-related issues as well, but I'd need to find them.

Is this a breaking change?

No.

[abonander]

@jcreekmore can you try this branch and see if it also eliminates the issue? I changed poll_ready() to schedule wakeups for both reads and writes where applicable.

[jcreekmore]

It also eliminates the issue. I technically didn't run this branch, but I cherry-picked the change on top of 0.8.6 so that I didn't have to worry about pulling in any other changes that have occurred in the interim.