The server can change the connection ID with the first Handshake packet.
Afterwards, packets with different source connection IDs have to be
ignored. Otherwise, for example the retransmission of the Initial packet
might create two sessions on the server with different source connection
IDs on the server side, but the same connection ID on the client side.
FHL2 was an experiment in Chrome, run in Q036, which introduced HOL
blocking. This experiment is over, so we can remove the code to send a
PUBLIC_RESET when a peer initiates this experiment.
Instead of exposing a session.handshakeStatus() <-chan error, it's
easier to pass a callback to the session which is called when the
handshake is done.
The removeConnectionID callback is in preparation for IETF QUIC, where a
connection can have multiple connection IDs over its lifetime.
In gQUIC, the server completes the handshake first (after sending the
SHLO). In TLS 1.3, the client completes the handshake first (after
sending the CFIN).
They need to have some way to learn that the peer successfully completed
the handshake, so they can stop retransmitting the handshake packets
containing the SHLO or the CFIN, respectively. To achieve that, the peer
finishing the handshake last will send a PING frame in a forward-secure
packet.
It is not sufficient to check for connection-level window updates every
time a packet is sent. When a connection-level window update needs to be
sent, we need to make sure that it gets sent immediately (i.e. call
scheduleSending() in the session).
When the handshake completes, the crypto setup closes the handshakeEvent
channel. We need to make sure that the session run loop immediately
selects this case, and not any other case (especially the packet
reception case). Otherwise, the server crypto setup will deadlock,
because the sentSHLO channel won't be closed, and opening of
forward-secure packets will block indefinitely on that channel.
There's no need for a check if more than protocol.MaxTrackedSentPackets
packets were sent. There are certain situations where we allow (via
SendingAllowed()) sending of more packets, and we shouldn't throw an
error when the session then actually sends these packets.
