* pass a context to Transport.ConnContext
This context is cancelled when the QUIC connection is closed, or when
the QUIC handshake fails. This allows the application to easily build
and garbage collect a map of active connections.
* correctly handle fresh contexts returned from ConnContext
* use Transport.VerifySourceAddress to control the Retry Mechanism
This can be used to rate-limit handshakes originating from unverified
source addresses. Rate-limiting for handshakes can be implemented using
the GetConfigForClient callback on the Config.
* pass the remote address to Transport.VerifySourceAddress
* avoid lock contention when accepting new connections
The server used to hold the packet handler map's lock while creating the
connection struct for a newly accepted connection. This was intended to
make sure that no two connections with the same Destination Connection
ID could be created.
This is a corner case: it can only happen if two Initial packets with
the same Destination Connection ID are received at the same time. If
the second one is received after the first one has already been
processed, it would be routed to the first connection. We don't need to
optimized for this corner case. It's ok to create a new connection in
that case, and immediately close it if this collision is detected.
* only pass 0-RTT to the connection if it was actually accepted
* add Transport config options to limit the number of handshakes
* fix accounting for failed handshakes
* increase handshake limits, improve documentation
So far, we used Connection.destroy, which destroys a connection without
sending out a CONNECTION_CLOSE frame. This is useful (for example) when
receiving a stateless reset, but it's not what we want when the server
refuses an incoming connection. In this case, we want to send out a
packet with a CONNECTION_CLOSE frame to inform the client that the
connection attempt is being rejected.
There is no good reason to manually set the validity period for Retry
tokens. Retry tokens are only valid on a single connection during the
handshake, so it makes sense to limit their validity to the configured
handshake timeout.
