Draft: Resolve "Allow users to customize their JWT sub claim (MVC)"

• Please check this box if this contribution uses AI-generated content (including content generated by GitLab Duo features) as outlined in the GitLab DCO & CLA

What does this MR do and why?

This MR adds a new attribute to projects, named ci_id_token_sub_claim_components. Project admins can change the value of ci_id_token_sub_claim_components to produce tokens with more or less detailed sub claims.

The default value of ci_id_token_sub_claim_components is ["project_path", "ref_type", "ref"]. Each element of ci_id_token_sub_claim_components must name a custom JWT claim produced by GitLab, and the first element must be project_path.

JWTs created for id_tokens in CI now use this config to create the sub claim on the token. Each element of ci_id_token_sub_claim_components is formatted into <claim_name>:<claim_value>, joined with :. For the default value this will result in sub claims that reproduce the current fixed format, which looks like project_path:agroup/bgroup/myproject:ref_type:tag:ref:v4.2.0. Custom formatting and static values aren't permitted.

MR acceptance checklist

Issues that need to be addressed:

1. Tests
2. Documentation
3. Improving validation of ci_id_token_sub_claim_components at PUT time

How to set up and validate locally

Testing token production:

1. Update a project's ci_id_token_sub_claim_components value with PUT /projects/:id
2. Run a build that has id_tokens configured
3. Echo the token (echo $TOKEN | base64 or it will be masked)
4. base64d and verify

Testing relying parties:

1. Obtain a public IP, DNS name, and real (not self-signed) TLS cert for your instance
2. Configure the relying party correctly based on the DNS name from step 1 and customized sub claim
3. Do the steps in "Testing token production" except using the token rather than just printing it

Related to #360592 (closed)