Only set QUIC TLS 0-RTT client state if a 0-RTT handshake was attempted
Even if an SSL_SESSION is early data capable, it is still possible (for
various reasons) that BoringSSL will decide not to do a 0-RTT handshake.
TlsClientHandshaker should wait for a signal from BoringSSL that it is
attempting a 0-RTT handshake before it sets saved transport and application
state for early data.
Client-side only quic behavior change, not flag protected.
PiperOrigin-RevId: 320646436
Change-Id: Ib1cfe2640d3cd62e23344ede852b91756a44f687
7 files changed