Implement multi identity caller that looks at the server cert while selecting the client one

[sfc-gh-mjankowski]

The mTLS handshake and where we inject new logic

The diagram below shows the messages exchanged during a standard mTLS
handshake (TLS 1.2 flow shown for clarity; TLS 1.3 reorders some messages
but the certificate selection logic is equivalent). The highlighted step
is where MultiIdentityCredentials injects its identity-selection logic.

  Proxy (client)                                    Target (server)
  ─────────────                                     ───────────────
       │                                                  │
       │─── ClientHello ─────────────────────────────────▶│
       │    (supported ciphers, TLS version, random)      │
       │                                                  │
       │◀── ServerHello ──────────────────────────────────│
       │    (chosen cipher, TLS version, random)          │
       │                                                  │
       │◀── Server Certificate ───────────────────────────│
       │    (server's leaf cert + chain)                   │
       │                                                  │
       │    ┌─────────────────────────────────────────┐   │
       │◀───│ CertificateRequest                      │───│
       │    │  • AcceptableCAs: [CA-Acme, ...]        │   │
       │    │    (DER-encoded subject DNs of CAs the  │   │
       │    │     server trusts for client certs)      │   │
       │    └─────────────────────────────────────────┘   │
       │                                                  │
       │◀── ServerHelloDone ──────────────────────────────│
       │                                                  │
       │    ╔═════════════════════════════════════════╗   │
       │    ║  ** OUR NEW LOGIC RUNS HERE **          ║   │
       │    ║                                         ║   │
       │    ║  GetClientCertificate callback fires:   ║   │
       │    ║                                         ║   │
       │    ║  1. Read AcceptableCAs from the server  ║   │
       │    ║  2. For each identity we hold:          ║   │
       │    ║     - extract leaf cert's Issuer DN     ║   │
       │    ║     - check if it's in AcceptableCAs    ║   │
       │    ║  3. Return the first matching cert      ║   │
       │    ║     (or fall back to identity[0])       ║   │
       │    ╚═════════════════════════════════════════╝   │
       │                                                  │
       │─── Client Certificate ──────────────────────────▶│
       │    (the cert selected by our logic above)        │
       │                                                  │
       │─── ClientKeyExchange ───────────────────────────▶│
       │    (premaster secret encrypted with server key)  │
       │                                                  │
       │─── CertificateVerify ───────────────────────────▶│
       │    (signature proving we own the private key     │
       │     of the cert we just sent)                    │
       │                                                  │
       │─── [ChangeCipherSpec] ──────────────────────────▶│
       │─── Finished ────────────────────────────────────▶│
       │                                                  │
       │◀── [ChangeCipherSpec] ───────────────────────────│
       │◀── Finished ─────────────────────────────────────│
       │                                                  │
       │    ══════ Encrypted channel established ══════   │
       │                                                  │

In standard (single-identity) mTLS the client always sends the same
certificate regardless of what the server asks for. With
MultiIdentityCredentials, the GetClientCertificate callback inspects
the server's CertificateRequest and dynamically picks the right identity.

Proxy server wiring

The proxy server's credential extraction was refactored to support two paths:

• Single identity (zero or one clientCredSources): preserves the existing WrappedTransportCredentials behavior with its own refresh/metrics/logging.
• Multiple identities (two or more clientCredSources): loads each source as a ClientIdentity and creates a MultiIdentityCredentials.

The server-side (incoming) credentials are unchanged and still use the single credSource.

[sfc-gh-ssapkowski]

👍