buffer undecryptable 0-RTT packets
buffer undecryptable 0-RTT packets

Currently, incoming packets that can't be decrypted because the
corresponding read keys are not available yet are simply dropped. On the
server side this can happen with 0-RTT packets, for example if an early
handshake callback configured in BoringSSL delays installation of read
keys.

This change implements buffering a limited number of 0-RTT packets
received before the corresponding read keys are installed, for a short
period, so that they can be correctly processed at a later time. The
buffer is limited to 10 packets (no particular reason for this number,
though it is also what Chrome uses), and it should be drained as soon as
keys become available.

It can also happen that the server ends up rejecting 0-RTT anyway, in
which case the buffer is cleared as soon as the handshake is completed.
In theory this could happen at an earlier time during the handshake, but
BoringSSL does not (yet?) expose a signal for this.

This could, in theory, also be used to support the case where 0-RTT
packets are received before an Initial one. However it is up to the
application to decide whether a connection should be accept()ed even if
no valid Initial packet has been received yet, as well as dropping the
connection object after a certain amount of time in case the handshake
doesn't complete, as the idle timer is not armed if no Initial packet is
received.

cloudflare/quiche,cloudflare/quiche,cloudflare/quiche