Setting necessary QUIC parameters before 1RTT gets ready (2)

[kazu-yamamoto]

This is an alternative to #432. Context is passed to sync from client and server. RTT0Status is not exported since Information has infoIsEarlyDataAccepted.

[kazu-yamamoto]

An issue: if infoIsEarlyDataAccepted is False, there is no way to tell which fallback mode is used, PreSharedKey or FullHandshake?

[ocheron]

there is no way to tell which fallback mode is used

Yes, this is the current API, for QUIC and TLS.
The mode RTT0 is "sticky" and denote any attempt to use 0-RTT by the client.
Same, value PreSharedKey hides whether HRR was used.

Is this a problem operationally for QUIC?

[ocheron]

I prefer this approach for reasons explained previously in #432.

It's also better if "information" API to query the handshake mode or other parameters is similar between tls and quic. That doesn't mean tls API doesn't need to change too.

For operational purpose to implement QUIC protocol it could be necessary to expose more.
For example in tls the distinction RTT0Accepted / RTT0Accepted is not used but just exposed.
What is used operationally is: EarlyDataAllowed, EarlyDataNotAllowed, and RTT0Sent.

[kazu-yamamoto]

Is this a problem operationally for QUIC?

Essentially, no. But I'm afraid that users get confused.

[kazu-yamamoto]

Thank you for your review. I have merged this PR.

Since QUIC RFCs have not been published yet, we don't have to hurry up to releasing the next version for QUIC. So, we have time. Let me have more experience with this APIs.