[TLS] Add mTLS authentication (certificate-based FlussPrincipal)

[affo]

Search before asking

• I searched in the issues and found nothing similar.

Description

Part of #3786 (FIP-29: (m)TLS Support).

Wave 2 — depends on: SSL principal mapping (#3795), server pipeline integration (#3792).

Add mutual TLS as a new authentication mechanism — the server derives the authenticated FlussPrincipal from the client's X.509 certificate.

• MutualTlsAuthenticationPlugin, MutualTlsClientAuthenticator, MutualTlsServerAuthenticator, registered via the existing SPI (META-INF/services).
• Client authenticator returns a zero-length, non-null token on its first call — no real token exchange (the cert is presented at the TLS layer already); this just triggers the AuthenticateRequest round-trip so the server can extract the principal.
• Server authenticator reads the peer certificate from the connection's SSLSession, maps it via SslPrincipalMapper ([TLS] Extract SSL principal mapping (SslPrincipalMapper) #3795), returns FlussPrincipal; fails clearly if TLS isn't enabled on the connection.
• Non-breaking SPI addition: default method SSLSession sslSession() on ServerAuthenticator.AuthenticateContext (returns null for non-TLS connections).
• Per-listener ClientAuth.REQUIRE derivation: a listener whose security.protocol.map entry is mTLS now requires a client certificate — every other TLS listener stays encryption-only; no global client.auth option.
• TlsAuthenticationITCase — end-to-end mTLS handshake, principal derivation, and authorization test.

Depends on: SSL principal mapping (#3795), server pipeline integration (#3792).

Estimated diff size: ~875 lines.

(Note: narrower scope than originally drafted here — DN→principal mapping is now its own ticket, #3795.)

Willingness to contribute

• I'm willing to submit a PR!