fix: disable cross-SNI TLS session reuse in egress

[Kuromesi (Kuromesi)]

The MITM egress gateway shares an upstream TLS context across multiple hostnames. Envoy's session cache is not scoped by SNI, so a session established for one hostname can be offered to another. If the second origin accepts the ticket, the cached certificate identity may fail SAN validation, resulting in HTTP 503 responses.

Reproduction

The issue was reproduced by sequentially accessing https://cdn.npmmirror.com and https://open.feishu.cn through an egress gateway:

1. The first request completes a full TLS handshake and caches a session ticket.
2. The second request sends the correct SNI but includes the first origin's ticket.
3. The server accepts TLS 1.2 session resumption without sending a new certificate. Envoy rejects the cached certificate identity because it does not match the second hostname, returning 503.
4. Setting max_session_keys: 0 makes both connections complete full handshakes and reach their HTTP upstreams.

Reproduction depends on the second origin accepting the cached ticket and both connections using the same gateway TLS context.

Change

Set max_session_keys: 0 on all four MITM origin TLS clusters, covering HTTP and gRPC over both dynamic forward proxy and original-destination routing.

SNI, SAN/CA validation, and HTTP connection reuse remain enabled. New TLS connections require full handshakes. Revisit this workaround after upgrading to a build containing envoyproxy/envoy#45982 with SNI-scoped caching enabled.

• Unit tests pass, including race checks
• Targeted lint passes
• Configuration comments explain the workaround and removal condition
• Full make verify (code generation blocked by local Python 3.9)

No live Substrate handshake or performance testing was performed.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.