* Add support for providing a custom ConnectionID generator via Config
This work makes it possible for servers or clients to control how
ConnectionIDs are generated, which in turn will force peers in the
connection to use those ConnectionIDs as destination connection IDs when sending packets.
This is useful for scenarios where we want to perform some kind
selection on the QUIC packets at the L4 level.
* add more doc
* refactor populate config to not use provided config
* add an integration test for custom connection ID generators
* fix linter warnings
Co-authored-by: Marten Seemann <martenseemann@gmail.com>
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.
