Add groups to CI_JOB_TOKEN allowlist job_token/group_scope_link model

Original issue: #435903 (closed)

POC MR: !143106 (closed)

What does this MR do and why?

The current configuration for CI_JOB_TOKEN permissions relies on the project allow list, where permitted projects can be specified. The primary objective of the original issue is to expand this functionality by enabling permissions for CI_JOB_TOKEN on specific projects through group associations.

To include groups in the CI_JOB_TOKEN allow list, the initial step is to introduce the Ci::JobToken::GroupScopeLink model, along with the ci_job_token_group_scope_links table, featuring fundamental validations and attributes analogous to those in Ci::JobToken::ProjectScopeLink.

This is the 1st iteration of the issue: #435903 (closed).

To facilitate a smoother review process, the implementation has been divided into four iterations:

Iteration plan

1. Database design of group list table and model - job_token/group_scope_link 👈 you are here
2. Add into app/models/ci/job_token/group_scope_link.rb and app/models/ci/job_token/allowlist.rb groups validation together with inbound lists, Feature flag group_scope_link_allowlist (MR: !142441 (merged))
3. GraphQL implementation (MR: !143132 (merged))
4. REST API implementation

Database design and model details:

Main attributes:

1. source_project - responsible for the accessible project from current_project pipeline via CI_JOB_TOKEN
2. target_group - responsible for the allowed group, any project inside this group or recursively subgroup would be allowed to access accessible projects in the scope of pipeline execution using CI_JOB_TOKEN
3. added_by - represent a user created a record in the group allowlist.

Ensure consistency in naming by aligning with the existing implementation in app/models/ci/job_token/group_scope_link.rb.

Basic validations:

1. source_project_under_link_limit - Allowing not more than 200 groups in the allowlist source_project
2. source_project, target_group - presences validation

Foreign keys:

As ci_ database decomposes from the main, here we have loosened foreign keys:

1. source_project_id referenced to table projects, if any referenced source_project gets deleted from the main table project - we delete it from the group allow list table
2. target_group_id referenced to table namespaces - model groups, if any referenced target_group gets deleted from main table namespaces - we delete it from the group allow list table
3. added_by_id referenced to table users, if any referenced added_by user gets deleted we nullify added_by_id field.

Database anticipated usage

What is the anticipated growth for the new table over the next 3 months, 6 months, 1 year? What assumptions are these based on?

Similar to ci_job_token_project_scope_links - current usage 86173 rows at GitLab.com

How many reads and writes per hour would you expect this table to have in 3 months, 6 months, 1 year?

Very limited writes. Potentially more reads, based on pipeline execution with CI_JOB_TOKEN involved.

anticipated most popular query: SELECT * FROM ci_job_token_group_scope_links WHERE source_project_id=PROJECT_ID

Under what circumstances are rows updated? What assumptions are these based on?

Row updates will be infrequent for the foreseeable future.

Based on the anticipated data volume and access patterns, does the new table pose an availability risk to GitLab.com or self-managed instances? Does the proposed design scale to support the needs of GitLab.com and self-managed customers?

There is no risk due to anticipated data volume or access patterns, as we will have similar usage to ci_job_token_project_scope_links

SQL execution plan

SELECT * FROM ci_job_token_group_scope_links WHERE source_project_id=123;

Time: 1.089 ms
  - planning: 0.956 ms
  - execution: 0.133 ms
    - I/O read: 0.000 ms
    - I/O write: 0.000 ms 

Postgres AI - https://console.postgres.ai/gitlab/gitlab-production-ci/sessions/25729/commands/81180