[bug] Upstream TLS connector never resumes sessions: each new upstream connection does a full handshake #1114

Summary

The upstream TLS connector (pingora-core/src/connectors/tls/boringssl_openssl/mod.rs, 0.9.1) performs a full TLS handshake for every new connection to a TLS upstream. The SslConnector is built without a client session cache (set_session_cache_mode is never called) and connect() never calls ssl.set_session(), so neither TLS 1.2 session IDs nor TLS 1.3 tickets issued by the upstream are ever reused. The reused flag returned by get_http_session refers to a pooled connection, not to a resumed TLS session.

Why it matters

Whenever the keepalive pool cannot satisfy a request, the new connection pays a full handshake. That is the common case for:

• streaming / long-held requests over HTTP/1.1 to the upstream, where every concurrent stream needs its own connection (a burst of N streams = N full handshakes);
• mutual TLS upstreams, where the full handshake also carries the client certificate and its signature;
• post-quantum key shares (e.g. X25519MLKEM768), which make each full handshake noticeably heavier than a resumption.

nginx resumes upstream sessions by default (proxy_ssl_session_reuse on), so a side-by-side comparison of the two proxies on the same mutual-TLS upstream shows the upstream spending more CPU on handshakes behind Pingora than behind nginx, with the same client load.

Expected behaviour

An opt-in on the peer (e.g. PeerOptions::tls_session_reuse: bool) or on ConnectorOptions that:

1. enables the client session cache on the connector context (SSL_SESS_CACHE_CLIENT), with a new-session callback — TLS 1.3 tickets arrive after the handshake, so a callback is needed rather than ssl.session() right after connect;
2. stores the latest SslSession per peer key (address, SNI, ALPN, CA/verify settings), bounded in size;
3. calls ssl.set_session() before the handshake when a session for that key exists;
4. reports resumption in the digest (SslDigest) so callers can log it.

Environment

pingora 0.9.1 (pingora-core with the boringssl feature), Linux x86_64, upstreams are nginx with mutual TLS (TLS 1.3, ECDSA P-256 certificates).

I can prepare a PR along the lines above if the design is acceptable.