Properly handle 0-RTT accepting/rejecting

[camshaft]

https://tools.ietf.org/html/draft-ietf-quic-tls-32#section-4.6.2

A server accepts 0-RTT by sending an early_data extension in the
EncryptedExtensions (see Section 4.2.10 of [TLS13]). The server then
processes and acknowledges the 0-RTT packets that it receives.

A server rejects 0-RTT by sending the EncryptedExtensions without an
early_data extension. A server will always reject 0-RTT if it sends
a TLS HelloRetryRequest. When rejecting 0-RTT, a server MUST NOT
process any 0-RTT packets, even if it could. When 0-RTT was
rejected, a client SHOULD treat receipt of an acknowledgement for a
0-RTT packet as a connection error of type PROTOCOL_VIOLATION, if it
is able to detect the condition.

When 0-RTT is rejected, all connection characteristics that the
client assumed might be incorrect. This includes the choice of
application protocol, transport parameters, and any application
configuration. The client therefore MUST reset the state of all
streams, including application state bound to those streams.

A client MAY reattempt 0-RTT if it receives a Retry or Version
Negotiation packet. These packets do not signify rejection of 0-RTT.

[camshaft]

Closing for now until 0-RTT gets scoped out

[camshaft]

This issue is still referenced in code:

s2n-quic/quic/s2n-quic-tls/src/callback.rs

Line 166 in c25b075

// I couldn't find a good citation but here's the issue: https://github.com/aws/s2n-quic/issues/301

s2n-quic/specs/todos/tls/4.6.2.toml

Line 9 in c25b075

tracking-issue = "301"