Declare assignable_when conditions on the experiments API

What does this MR do and why?

This MR is one of seven that split !253276 (merged) into pieces that each need only Authorization approval plus at most one other CODEOWNERS section. This one needs Authorization and Growth Experiments.

A consumer earns a condition tag only when it rejects every request from a caller who does not meet the condition, for every parameter. Partial checks, feature flags, and license checks do not count. The gitlab_team_member condition covers gitlab_team_member? checks. Nothing changes at request time. The only effect is that the token creation UI stops offering a permission at boundaries where the current user does not meet the condition.

This MR tags the 1 REST consumer (ee/lib/api/experiments.rb, 5 routes) with the gitlab_team_member condition, 5 tags in total. 4 YAML files gain assignable_when: gitlab_team_member: system_access/experiment/read, system_access/experiment_cache/delete, and the new system_access/experiment_assignment/create and system_access/experiment_assignment/delete.

The two assignment routes previously deferred granular token support with a todo decorator on their route_setting :authorization. They now declare the create_experiment_assignment and delete_experiment_assignment permissions at the instance boundary, using the same gitlab_team_member condition described above. Two raw permission definitions and two assignable permission files were added to back these new permissions. The request spec for these routes now uses the shared authorizing granular token permissions examples instead of asserting that granular tokens are denied.

References

• Original MR being split: !253276 (merged)
• Parent MR that added GraphQL assignable_when support: !253246 (merged)
• MR that introduced assignable_when for REST endpoints: !246776 (merged)
• Sibling MRs from the same split:
  • !253276 (merged) (Declare admin assignable_when conditions on granular token consumers)
  • !255011 (merged) (Declare SaaS and self-managed assignable_when conditions)
  • !255014 (merged) (Declare assignable_when conditions on Geo granular token consumers)
  • !255015 (merged) (Declare assignable_when conditions on system hook consumers)
  • !255016 (merged) (Declare assignable_when conditions on the admin token API)
  • !255022 (merged) (Declare assignable_when conditions on CI granular token consumers)

Screenshots or screen recordings

No UI changes in this MR.

How to set up and validate locally

1. Run bundle exec rake gitlab:permissions:validate. It passes.

2. Remove the assignable_when: block from config/authz/permission_groups/assignable_permissions/system_access/experiment/read.yml and run the task again. It fails and lists the consumer in ee/lib/api/experiments.rb with Consumer conditions: [gitlab_team_member]. Restore the block.

3. Enable the granular_personal_access_tokens feature flag, then query the GraphQL accessTokenPermissions field (or open the fine-grained token creation page) for read_experiment as a non-team-member versus as a GitLab team member. The non-team-member does not get INSTANCE.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.