When receiving a packet with an IETF QUIC Header using an unsupported
version, we should send a IETF QUIC Version Negotiation Packet, even if
none of the supported versions is IETF QUIC.
A server is allowed to perform multiple Retries. There's little to gain
from doing so, but it's something our API allows. If a server performs
multiple Retries, it must use a connection ID that's at least 8 bytes
long. Only if it doesn't perform any further Retries it is allowed to
use shorter IDs. Therefore, we're on the safe side by always using a
long connection ID.
This shouldn't have a performance impact, since the server changes the
connection ID to a short value with the first Handshake packet it sends.
The destination connection ID on the Initial packet must be at least 8
bytes long. By using all valid values, we make sure that the everything
works correctly. The server chooses a new connection ID with the Retry
or Handshake packet it sends, so the overhead of this is negligible.
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.
mint doesn't verify the certificate chain. This change forces users of
quic-go to acknowledge mint's insecure behavior by explicitely setting
InsecureSkipVerify.
