[fix][broker] Authorize cluster listing requests

[ChimdumebiNebolisa]

Fixes #26100

Motivation

GET /admin/v2/clusters returned cluster names without invoking the cluster authorization path. Authenticated users without the global cluster-list permission could therefore enumerate clusters.

Modifications

Authorize cluster listing with ClusterOperation.LIST_CLUSTERS using the established null global-resource scope before reading cluster metadata. Added endpoint-level coverage for authorized and denied requests, including verification of the authorization operation and scope.

This is intentionally a v5/master-only behavior change: third-party AuthorizationProvider implementations must support this cluster operation and global null scope for non-superuser requests.

Verifying this change

• Make sure that the change passes the CI checks.

This change added tests and can be verified as follows:

• gradlew.bat --no-daemon --rerun-tasks :pulsar-broker:test -PtestRetryCount=0 --tests org.apache.pulsar.broker.admin.ClusterEndpointsAuthorizationTest
• gradlew.bat --no-daemon --rerun-tasks :pulsar-broker:spotlessJavaCheck :pulsar-broker:checkstyleMain :pulsar-broker:checkstyleTest
• git diff --check

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

[nkurihar]

Thanks for the fix. I have a few questions/comments:

• My understanding is that the primary motivation is to make the authorization model consistent across the Admin APIs, rather than to address a security vulnerability. Is that correct?
• I don't expect this change to cause issues in practice (it would also work fine in our production environment). That said, it is still a compatibility change, as existing clients that could call GET /admin/v2/clusters will now require superuser privileges.
• Have you considered making this behavior optional (e.g. via a broker configuration), so operators can preserve compatibility if needed during upgrades?

I'm not against this change; I'd just like to better understand the motivation and whether a compatibility option has been considered.