Using varints to encode the Transport Parameters

[Marten Seemann <[e-mail]>]

This is based on issue https://github.com/quicwg/base-drafts/issues/1608.

The proposal is to change the encoding of the QUIC Transport Parameters
exchanged during the handshake, in order to achieve greater consistency
with how QUIC encodes values, and also to save a few bytes.

We have a few things that are called transport parameters. This proposal
only applies to the TransportParameter struct as defined in section 18 as:
*struct {*
*      TransportParameterId parameter;*
*      opaque value<0..2^16-1>;*
*} TransportParameter;*
According to the encoding defined by the TLS spec, every key-value pair
will be serialized as:
TransportParameterID (2 byte), length (2 byte), value (length byte)
where the length of the value is specified for each TransportParameterID.

We could switch to varint encoding, as follows:

1. for the TransportParameterID: Since we’re only using the code points 0
to 13, we could save one byte per ID by using a varint.
2. for the length: We would save one more byte, as long as the length of
the value is less than 16 byte (which will be the case for all values
except the preferred_address).
3. For numeric values: This would apply to the flow control offsets, the
maximum stream IDs, the ack delay exponent , the maximum packet size and
the max_ack_delay.

In addition to the byte-savings of 1. and 2., 3. has some more desirable
properties:
    1. It would allow us to encode the whole range of permitted values. For
example, initial_max_data is a 62-bit value, but the current encoding just
allows to send 4 bytes.
    2. Depending on the value sent, this might or might not save a byte
here and there.
    3. We’d be consistent with the encoding we use everywhere else.