[improve][broker] PIP-485: Configurable mTLS principal mapping (SAN sources and DN mapping rules)

[PavelZeger]

Motivation

Pulsar's built-in TLS auth provider (AuthenticationProviderTls, in pulsar-broker-common) derives a client's role only from the certificate's first Common Name (CN), and the extraction is hardcoded; if the CN is empty or missing, authentication fails outright. That is a poor fit for two increasingly common
deployments:

• Enterprise PKI, where identity lives in another DN field (an OU, emailAddress, or the full DN) and re-issuing certificates just to populate the CN isn't practical.
• SPIFFE/SPIRE and service meshes, where workload identity is a URI SAN (spiffe://...) and the CN is intentionally empty — those certificates are rejected today even though they carry a valid, cryptographically-bound identity.

Apache Kafka solves this declaratively with ssl.principal.mapping.rules (KIP-371). Pulsar has no equivalent for its built-in provider, and writing a custom AuthenticationProvider is a high bar for what should be a few lines of config.

Modifications

This PR adds the PIP-484 design document (pip/pip-484.md) for community discussion and vote. It contains no code changes.

The proposal describes two backward-compatible config options for AuthenticationProviderTls:

• tlsCertIdentitySource — choose the raw identity: CN (default), DN, or SAN:URI|DNS|EMAIL.
• tlsAuthPrincipalMappingRules — an ordered list of Kafka-style RULE:/DEFAULT mapping rules.

With both unset, behavior is identical to today (first CN, fail on empty CN). The document also covers the proxy config plumbing, new auth-failure error codes, security considerations, and upgrade/rollback compatibility.

Verifying this change

• Make sure that the change passes the CI checks.

This change is a trivial rework / code cleanup without any test coverage.

Documentation only: this PR adds the PIP-484 proposal markdown file and contains
no production code. Implementation (with tests) will follow in separate PRs that
reference this PIP, after the proposal is accepted.

Does this pull request potentially affect one of the following parts:

• Dependencies (add or upgrade a dependency)
• The public API
• The schema
• The default values of configurations
• The threading model
• The binary protocol
• The REST endpoints
• The admin CLI options
• The metrics
• Anything that affects deployment