[zmstone]

Problem

A proxied connection to an SSL listener has two places a client certificate can
come from, and which one holds it depends on where TLS was terminated.

• A proxy that terminates mTLS (HAProxy with send-proxy-v2-ssl-cn) forwards the
  client's details in the PROXY V2 SSL TLVs. The inner handshake is one-way, or
  carries the proxy's own certificate.
• A TCP-passthrough proxy (NLB, Traefik tls: passthrough) terminates nothing. It
  sends no SSL TLVs, and the client certificate is on the inner ssl_socket.

PR #218 made peercert/1, peer_cert_subject/1 and peer_cert_common_name/1
delegate to the inner ssl_socket unconditionally when the listener is SSL. That
fixed the passthrough deployment and broke the terminating one, which had worked
before, because the TLV clause became unreachable.

Deployments

	Deployment	Where the client cert actually is	Before #218	After #218	With this PR
A	Passthrough proxy (NLB, Traefik tls: passthrough) + TLS listener, client mTLS to EMQX	inner TLS session; no SSL TLVs sent	broken	works	works
B	Proxy terminates mTLS + plain TCP to EMQX + TCP listener	PP2 SSL TLVs	works	works	works
C	Proxy terminates mTLS + re-encrypt to EMQX + TLS listener, one-way inner	PP2 SSL TLVs	works	broken	works
D	As C, but the proxy also presents its own client cert on the inner hop	PP2 SSL TLVs; the inner cert is the proxy's	works	wrong identity, reports the proxy as the client	works

Row D does not fail loudly today. It reports HAProxy as every client.

Rows C and D are a 5.x to 6.x upgrade regression rather than a long-standing gap.
#218 first shipped in esockd 5.16.2, and the EMQX lines pin either side of it:

EMQX branch	esockd	behaviour
dev-58	5.13.0	reads the TLVs
dev-510	5.14.0	reads the TLVs
dev-60	5.17.7	reads the inner socket
dev-63	5.17.8	reads the inner socket

Change

Read the SSL TLVs first. Use the inner socket only when the header carries no
certificate information. Every row above then works, which neither predecessor
achieved.

The PROXY header comes from the hop closest to the client, so when it carries
certificate information it describes the client. An inner certificate on a
re-encrypted hop belongs to the proxy, not the client. Enabling proxy_protocol
on a listener already declares the upstream trusted — the peer address comes from
the same header and is already used that way — so this adds no new trust
assumption, and no new option: the listener either trusts the header or does not
enable the feature.

One predicate, pp2_ssl_info/1, picks the source for all three accessors.
Deciding per accessor would let peercert/1 report the proxy's certificate while
peer_cert_common_name/1 reports the client's, because a proxy can send the SSL
TLV without the CN sub-TLV.

peersni/1 takes the same precedence, for the same reason: the authority TLV is
the name the client asked for, the inner SNI is whatever the proxy chose when it
opened the re-encrypted hop.

Tests

Three cases pin rows A, C and D, so none can be traded for another again:

• t_peercert_proxy_ssl/1 (from fix: read peercert from inner ssl_socket on proxied SSL listeners #218) — row A. Passthrough proxy, PROXY V1, no
  TLVs. The inner socket is the only source. Unchanged and still passing.
• t_peercert_proxy_ssl_pp2_fallback/1 — row C. Terminating proxy, one-way inner
  TLS, PROXY V2 with a PP2_SUBTYPE_SSL_CN. The TLVs are the only source.
• t_peercert_proxy_ssl_pp2_wins_over_inner/1 — row D. Both populated: mTLS on
  the inner hop and SSL TLVs in the header. Pins the precedence this PR chooses.

Negative controls: the row C case fails on master with
{false,undefined,undefined}; the row D case fails against inner-first
precedence.

Full suite: 240 passed, 3 skipped (pre-existing, remote TCP test server absent).