Buffer TLS handshake/application packets if TLS poll call returns Pending during the handshake #2601
Description
A test was added in #2574 that made the TLS provider return pending and do a self-wake for every call to poll(). This slowed down the handshake in the test, even though it logically should not because self-wakes do not actually use up any wall clock time. This behavior is caused by the fact that s2n-quic does not store any packets that it can't decrypt yet:
When a quic server sends a Server Hello to the Client, and the Client TLS provider returns Pending, the Handshake packet after this Server Hello will be dropped. This is because it is in the processing of the ServerHello that the keys to decrypt the next handshake messages are generated. We will drop the next handshake packet if those keys don't exist by the time we try to read the packet. The consequence of this is that now the client has to wait for the server to notice the packet wasn't acked and resend the Handshake packet, which has performance impacts for the TLS handshake.
There is a second place where this could occur as well. If the client sends its Client Finished message along with an Application data packet, that Application data packet will be dropped.