[bindings] Apply async blinding

[lrstewart]

Description of changes:

This one's a little long, but mostly tests.

Currently, TlsStream uses the default built-in blinding, which means that a blinded error causes the underlying s2n-tls library to block the thread until the blinding delay (10-30s) has passed. Instead, we need to use self-service blinding and wait asynchronously on the blinding.

I added the wait to poll_shutdown(). s2n-tls actually enforces the wait immediately when the error occurs (so in s2n_negotiate or s2n_recv), but that complicated the implementation since I'd need to save the result of s2n_negotiate and s2n_recv to be returned after the blinding. Enforcing the blinding in shutdown should be sufficient, since shutdown is what responds to the peer and closes the connection.

I also added logic to call shutdown if the handshake fails. Because the TlsStream isn't returned to the caller if the handshake fails, the caller can't be responsible for gracefully shutting down connections after failed handshakes. We need to do it for them.

Currently, calling s2n_shutdown usually doesn't work:

• If a close_notify alert is received during s2n_negotiate, it is not considered an error and the handshake tries to continue. However, there will be no more data, so the handshake just hangs. I added a minimal fix for this by at least checking that the connection isn't closed before trying to continue the handshake.
• If a blinded error occurs during s2n_recv, and we try to call s2n_negotiate afterwards, usually the fatal error in s2n_recv will have left the connection in such a state that it can't receive the peer's close_notify and s2n_shutdown will fail. I did not fix this bug as part of this PR.

Testing:

Testing this proved a little tricky, since it required specific errors from send / receive. All the existing test utilities I found required knowing the exact sequence of reads and writes, which we don't because of the handshake. So I added a little test stream that allows read and write to be temporarily overridden, but usually just calls a real stream.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[maddeleine]

So I guess what you're trying to say is that s2n_connection_get_delay isn't Fallible? I am not following this explanation.

[lrstewart]

s2n_connection_get_delay is Fallible, just in a really unfortunate way. I updated the comment-- does that makes it clearer?

Probably important to note that this is "impl Fallible for u64", meaning it's for an unsigned int.