KAFKA-20295: Use current quorum voters for feature validation

[lh0156]

KAFKA-20295: Use current quorum voters for controller feature validation

The controller feature validation path currently iterates every controller registration in the metadata image. With a dynamic quorum, a controller can be removed from the Raft voter set while its historical registration remains in the image. If that registration advertises an older metadata.version range, it can incorrectly prevent a valid metadata.version upgrade.

This change exposes the current voter IDs from Raft and passes them through the cluster feature support describer. Feature validation now checks registered controller capabilities only for current quorum voters and requires each current voter to have a registration. Existing describers that do not provide dynamic voter IDs retain the static QuorumFeatures fallback.

Testing:

• ./gradlew :metadata:test --tests org.apache.kafka.controller.FeatureControlManagerTest --no-build-cache
• ./gradlew :raft:test --tests org.apache.kafka.raft.KafkaRaftClientReconfigTest --no-build-cache
• ./gradlew :metadata:test --no-build-cache
• ./gradlew :metadata:spotlessCheck :raft:spotlessCheck --no-build-cache
• ./gradlew :raft:kafkaPublicApiChecker :metadata:kafkaPublicApiChecker --no-build-cache
• git diff --check

The regression tests cover both stale registrations from removed voters and missing registrations for current voters. Jira: https://issues.apache.org/jira/browse/KAFKA-20295

Reviewers: Davide Armand davide.armand@aiven.io

[davide-armand]

Should this target 4.0-4.3 branches instead of trunk?
I believe that since the proper fix for this is on its way to trunk, this workaround is likely not needed on trunk.

About the PR, should it prevent an outdated controller from rejoining the quorum if it was bypassed by feature upgrade script?
I actually drafted a similar PR and added a guard for that case.