[gianlucam76]

GET /profile lists the clusters a profile matches and drops the ones the user
is not allowed to see. It did this with one SubjectAccessReview per matching
cluster, each one a call to the API server, each one with a new clientset. A
profile matching 1,000 clusters meant 1,000 calls, even for a user who can
see every cluster.

This asks once, per cluster type, whether the user can get all SveltosClusters
(or all CAPI Clusters) in all namespaces. If so, every cluster of that type is
allowed without further calls. Otherwise the existing per-cluster check runs,
as before.

The shortcut uses the get verb, not list, so the answer cannot change for
any user: cluster-wide get on the resource implies get on each cluster. A user
whose get is limited to some namespaces or to named clusters is denied the
cluster-wide check and falls back to the per-cluster path. For those users the
result is the same as before, and the cost is one extra call per cluster type.

canGetCluster and the other check helpers are unchanged.

Measured on envtest, calling getProfileSpecAndMatchingClusters with real
SubjectAccessReviews, on main and on this branch (3 to 10 iterations on one
machine, indicative only):

User who can get all clusters, 1,000 matching clusters:

• 1,000 SubjectAccessReviews per request before, 1 after.
• 238 ms before, 1.4 ms after.
• 61 MB allocated per request before, 1.4 MB after. Most of it was the
  clientset built for each check.
• With 5 ms added to every SubjectAccessReview to stand in for network
  latency (simulated, not measured on a real API server): 7.4 s before, 9 ms
  after.

User who can get only some clusters (a rule naming one cluster):

• 1,000 checks before, 1,001 after.
• 239 ms before, 242 ms after.
  So there is no gain for these users, and the cost is the same within noise.

Tests:

• Specs against an RBAC-enabled envtest apiserver count the
  SubjectAccessReview requests that reach it: 1 for 20 clusters for a user
  who can get all SveltosClusters, 2 for a mix of SveltosClusters and CAPI
  Clusters, and 1 plus one per cluster for a user limited to a named cluster,
  who is allowed only that cluster. A user with no permission is denied every
  cluster.
• With the shortcut disabled, the counting specs fail (21 requests instead
  of 1, 12 instead of 2).
• The ui-backend rollout e2e spec passes against kind clusters running this
  image. It uses an admin token, so it goes through the shortcut.

🤖 Generated with Claude Code