Remember active_connection_id_limit for 0-RTT

[martinthomson]

Simple. It appears as though I missed this when @marten-seeman added
this transport parameter. We shouldn't make more exceptions for 0-RTT.

Closes #3423.

[marten-seemann]

This is a bigger design change than it might look like from the diff.

Our design principle was to only remember things for 0-RTT that are actually needed to make 0-RTT work. This means that we need the flow control limits as well as the stream number limits, because obviously the client needs to be able to send application data in 0-RTT.
This saves state on the client side (because the client only needs to remember those 6 parameters) as well as in the session ticket (because that’s how the server stores that state). A reasonable implementation strategy on the server is to reject 0-RTT if those parameters changed / were reduced, so keeping the number of things to remember small increases the probability that 0-RTT is not rejected.

[MikeBishop]

"needed to make 0-RTT work" has slightly fuzzy boundaries, though. A more concrete rendering of the principle is that the client needs to remember any limit which it might exceed prior to receiving the actual limit in the ServerHello. The possible solutions for any given TP, then, are to structurally ensure that the client can't exceed it in 0-RTT or to remember it.

[mikkelfj]

From comment #3426 (comment)
How is the TP to be remembered when it is to be ignored when 0 length CID is received?

[ianswett]

Besides the motivation of minimizing exceptions in 0-RTT, I'm not sure why we're making this change? Remembering more TPs makes server upgrades and config changes potentially more disruptive, as has been discussed, and there's no critical use case for the client to send NEW_CONNECTION_ID in 0-RTT.

[marten-seemann]

I agree with @ianswett. Although a client could decide to not remember the active_connection_id_limit (and would then not not be able to send more than one CID in 0-RTT packets), the server needs to store this value in order to decide whether to accept or to reject 0-RTT. This seems like a bit of a hassle for something that doesn't provide any real-world benefits.

[ianswett]

After looking back at the notes(linked on the issue), I see we had fairly strong agreement on this at the time, so I'm willing to let that stand, even if it's not what I think is the optimal choice.