Decide on Latency Spin Bit behavior for QUIC-LY

[lilalinda]

We are starting with Spin Bit turned off (so that it is DISABLED for all QUIC-LY connections). This makes sense as QUIC-LY should only be used in a tightly controlled, firewalled, experimental setup where we assume more access to latency measurements from inside the experiment. Therefore, no external estimates are needed.

If we keep this behavior, we should add a section to the specification document to this effect.

See about DISABLING the spin bit in Section 17.4 of RFC 9000, most notably:
"When the spin bit is disabled, endpoints MAY set the spin bit to any value and MUST ignore any incoming value. It is RECOMMENDED that endpoints set the spin bit to a random value either chosen independently for each packet or chosen independently for each connection ID."

[lilalinda]

When updating the spec, also talk about Key Phase in Short Headers:

key_phase is only meaningful when you have 1-RTT packet protection and key updates. Since QUIC-LY has no protection, there are no key phases to signal.

So: set it to False (0) on send, and ignore it on receive.

If you want to be explicit in the spec/impl:

Sender: MUST set the Key Phase bit to 0 in all Short Header packets.
Receiver: MUST NOT interpret the Key Phase bit; MAY accept either 0 or 1 (treat as don’t-care), optionally log if it’s 1.