Client storage of tokens should be independent of other stored state

[nharper]

For a 0-RTT resumption in H3, a client needs 4 pieces of state previously received from a server:

1. a NewSessionTicket
2. Transport Parameters
3. SETTINGS
4. a token (from a NEW_TOKEN frame)

The last isn't strictly necessary, but without it the server is likely to burn a round trip with a Retry packet to prove the client controls the source address.

On a given connection, there is only one server SETTINGS and Transport Parameters, though there may be multiple NewSessionTickets and tokens.

The first 3 pieces of state are necessarily required to have come from the same connection. A NST (from any connection) is needed since without it resumption can't happen. Transport Parameters and SETTINGS must come from somewhere for 0-RTT to be useful; the obvious and currently specified place is the SETTINGS and Transport Parameters that were sent on the same connection the NST came from.

There's no such need that the 4th piece of state come from the same connection as the others. The token is used to prove that the client controls the address the packet is purportedly coming from. This can be done separately from any crypto state (in the NST), application state (SETTINGS), or the rest of the transport state (Transport Parameters).

For a client to store the state needed for 0-RTT resumption, one possible implementation is to create cache entries containing an NST, TP, and SETTINGS. It's easy to do that where the TP and SETTINGS get duplicated N times, assuming N NSTs were received on a connection. If M tokens were received on that connection, and tokens need to be added to those cache entries, either the M tokens need to be paired to the N NSTs somehow, or all M tokens are in all N cache entries. This introduces noticeable complexity to a client's session cache implementation to correlate unrelated things.

It should be clarified that the client doesn't need to associate the token with the rest of the state needed for 0-RTT. #3150 has suggested wording for that clarification.

[kazuho]

As pointed out in @martinthomson in #3150 (review), the proposed change essentially forbids a server from storing SETTINGS in the token. I think I'm persuaded by @nharper's argument above that we'd better forbid such coordination, as it would be a burden to certain client implementations.

OTOH, I think that untying the relationship between session tickets and tokens does open a new issue, see #3155.