[improve][broker] PIP-490: Zero-downtime token signing-key rotation for the built-in JWT provider

[PavelZeger]

Motivation

Pulsar's built-in JWT provider (AuthenticationProviderToken) validates every token against a single key that is loaded once at startup and never reloaded. As a result, a signing key cannot be rotated without downtime: there is no window in which both the old and the new key are accepted, so operators must re-issue every token and flip the broker/proxy config in lockstep - in practice a coordinated restart - rejecting "wrong-key" tokens during the switch. That turns key-compromise response into an outage and discourages routine rotation, even though AuthenticationProviderOpenID already resolves keys by kid from a multi-key set.

Modifications

Adds the design document only - pip/pip-490.md. No code changes.

The proposal covers:

• Replacing the single validation key with an immutable, kid-indexed key set (kid → key + algorithm), resolved per token via jjwt's keyLocator.
• A local JWKS as the multi-key format (parsed with jjwt's Jwks/JwkSet), so each key carries its kid, type, and algorithm - which also closes the JWT algorithm-confusion (RS256 → HS256) surface a naive multi-key design would open.
• Hot reload of the key set on a timer, with an atomic swap and last-good-set retention.
• New config keys (tokenValidationKeysJwks, tokenValidationKeysRefreshSeconds, tokenRequireKid) mirrored into ProxyConfiguration; an optional pulsar tokens create --key-id; a new INVALID_TOKEN_KID error code.
• Exact backward compatibility when only the existing single-key settings are used.

Implementation will follow in a separate [improve][broker] PR once the PIP is accepted.

Verifying this change

• Make sure that the change passes the CI checks.

This change is a documentation-only design proposal (adds pip/pip-490.md); it contains no code and therefore no test coverage.

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

• Dependencies
• 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

None - this PR adds a design document only. (The proposal describes future config, CLI, and metrics changes; none are introduced by this PR.)