Add new QUIC extension IANA

[lrstewart]

Problem:

QUIC changed the IANA value for its quic_transport_parameters extension after draft 32. Previously, it was 0xffa5, but now it is 0x39.

Solution:

We should continue accepting quic_transport_parameters that use 0xffa5, while also supporting 0x39.

We can do this by creating duplicates of the quic_transport_parameters client and server extension structures but with the new 0x39 iana value.

We'd need to update s2n_quic_transport_params_recv to either safely overwrite any existing peer_quic_transport_parameters or to throw an error if the peer_quic_transport_parameters are already set.

We'll also need to update the s2n_quic_transport_params_if_missing method to only consider it an error if neither extension is received. We could use a separate flag, or we could not take any action if the first version is missing and check when the second version is missing if the first was also missing using extension_requests_received.

We'll also have to decide if we want to send both versions of the client extension, or only send one. Sending both would ensure our peer recognizes at least one, but would increase the size the of the message, which can be an issue for QUIC.

• Does this change what S2N sends over the wire? Yes. It changes an extension / adds another extension.
• Does this change any public APIs? No.
• Which versions of TLS will this impact? TLS1.3 with QUIC

Requirements / Acceptance Criteria:

What must a solution address in order to solve the problem? How do we know the solution is complete?

• RFC links: Links to relevant RFC(s)
• Related Issues: Link any relevant issues
• Will the Usage Guide or other documentation need to be updated?
• Testing: How will this change be tested? Call out new integration tests, functional tests, or particularly interesting/important unit tests.
  • Will this change trigger SAW changes? Changes to the state machine, the s2n_handshake_io code that controls state transitions, the DRBG, or the corking/uncorking logic could trigger SAW failures.
  • Should this change be fuzz tested? Will it handle untrusted input? Create a separate issue to track the fuzzing work.

Out of scope:

Is there anything the solution will intentionally NOT address?