Connection ID lengths 1, 2 and 3

[Marten Seemann <[e-mail]>]

First of all, I realise that I'm bringing this up late in the process, and
maybe too late, since this would require a change to the invariants.

The connection IDs can be either 0 bytes or anything between 4 and 18 bytes
(inclusive). Lengths of 1, 2 and 3 bytes are not possible.
For p2p applications, and for server deployments that are not doing
connection ID based load balancing, it would be interesting to use shorter
connection IDs. One might imagine that a peer encodes the length of the
connection ID into the first few bits, and then starts using 1 byte
connection IDs first, and successively moves to longer lengths only when
handling more connections. A p2p host handling several thousand
simultaneous connections (which will be enough for many p2p protocols)
would never have to use anything longer than 2 byte connection IDs.

In the connection ID length field in the Long Header, we only have to 4 bit
to encode a range of 19 values (we want 0 byte connection IDs, and we want
to support 18 byte connection IDs), so *some* values have to be left out.
However, leaving out 1, 2 and 3 seems a bit unfortunate, as there will be
more use cases for these values than e.g. for 13, 14 and 15 bytes.