Motivation:
Some trust manager implementations produce custom user principals and store them in the SSLSession. Resumed TLS sessions, however, don't always recover the stored contents. For instance, with TLSv1.3 stateless session resumption, our TLS implementations only store the peer certificate chain (or even just the leaf cert) in the session ticket. In such a case, the trust manager would like to be notified of the resumption, so that the peer principal can be recreated and stored in the session once again.

Modification:
Add a ResumableX509ExtendedTrustManager interface, with callbacks for resumed client and server sessions. Add infrastructure (the ResumptionController) to detect session resumption in an SSLEngine implementation agnostic way; if a TLS handshake completed without any calls to the TrustManager, then we've made a "stateless resumption" (hand-wave details) and should call the appropriate resume method. The JDK APIs don't provide a method to reliably discern if a session has been resumed, so we instead detect if the trust manager was called during the handshake. We do this by wrapping user-supplied trust managers that implement the ResumableX509ExtendedTrustManager interface. The wrapper will monitor calls to the trust manager and register the relevant SSLEngine in the controller — the engine is the object that the trust manager and the SslHandler both have access to, which reliably identifies the specific TLS session. Before finished the handshake, the SslHandler queries the ResumptionController to see if the trust manager has already been called, or if it needs to be notified of resumption. Since it's possible that the peer certificates have expired since the initial session, the trust manager gets another change to throw CertificateException.

Result:
Handlers that expect to find user principals in the authenticated SSLSessions no longer find empty sessions, provided they use a trust manager that correctly implements ResumableX509ExtendedTrustManager.

This is a draft to gage if the general approach is sane. There's still a few things that need to be done:

• Javadocs.
• Tests where the resume* methods throw CertificateException.
• Tests for different transports.
• Tests that use TCP FastOpen.
• Tests that use startTls.