[Feature] Support listener-specific SASL enabled mechanisms

[litiliu]

Search before asking

• I searched in the issues and found nothing similar.

Motivation

Fluss currently supports selecting different authentication protocols for different listeners through security.protocol.map. However, all SASL listeners share the global security.sasl.enabled.mechanisms configuration.

This becomes limiting when adding OAUTHBEARER support in #3495. A common deployment may want to expose OAUTHBEARER only on the client-facing listener while keeping PLAIN on an internal listener. With only a global mechanism list, every SASL listener enables the same mechanisms, which couples otherwise independent listener security configurations.

Solution

Add listener-specific SASL enabled-mechanism configuration:

security.sasl.enabled.mechanisms=PLAIN
security.sasl.listener.name.client.enabled.mechanisms=OAUTHBEARER

Expected semantics:

• security.sasl.listener.name.<listener>.enabled.mechanisms overrides the global security.sasl.enabled.mechanisms for that listener.
• If the listener-specific option is absent, fall back to the global option to preserve the existing behavior.
• SASL mechanism matching must use the enabled mechanisms resolved for the connection's listener.
• Listener and mechanism matching should retain the current case-insensitive behavior.
• Add tests covering listener override, global fallback, and rejection of a mechanism that is not enabled on the target listener.

Anything else?

This capability allows different SASL listeners to enable different mechanisms. For example, a client-facing listener can enable only OAUTHBEARER, while an internal listener enables only PLAIN.

Willingness to contribute

• I'm willing to submit a PR!