QUIC: refined sending CONNECTION_CLOSE in various packet types.

As per RFC 9000, section 10.2.3, to ensure that peer successfully removed
packet protection, CONNECTION_CLOSE can be sent in multiple packets using
different packet protection levels.

Now it is sent in all protection levels available.
This roughly corresponds to the following paragraph:

* Prior to confirming the handshake, a peer might be unable to process 1-RTT
  packets, so an endpoint SHOULD send a CONNECTION_CLOSE frame in both Handshake
  and 1-RTT packets.  A server SHOULD also send a CONNECTION_CLOSE frame in an
  Initial packet.

In practice, this change allows to avoid sending an Initial packet when we know
the client has handshake keys, by checking if we have discarded initial keys.
Also, this fixes sending CONNECTION_CLOSE when using QuicTLS with old QUIC API,
where TLS stack releases application read keys before handshake confirmation;
it is fixed by sending CONNECTION_CLOSE additionally in a Handshake packet.

0 files changed, 0 insertions, 0 deletions