Allow users to customize their JWT sub claim

Proposal

The sub claim was recently introduced to support additional cloud providers. It currently has group, project, and ref (branch/tag) support. While the JWT token includes the environment, Vault is one of the only providers that can support any attributes passed in the jwt token.

AWS only supports a few claims(sub, iss, aud) - see comment here. I see two possible routes:

Proposal 1: Append environment onto sub (our preferred option)

(based on #360592 (comment 1219141126)) Allow users to customize their sub claim using only the available claims in the token, making the sub claim configurable via the API, this way we can ensure that there would be no option for users to inject customized values to the claim (to avoid impersonation).

Open question - which role/privilege will have the ability to customize the sub claim

Proposal 2: Append environment onto sub.

Workflow would be the following

1. If no environment is defined, default to: project_path:mygroup/myproject:ref_type:branch:ref:main.
2. If environment defined, append environment name: project_path:mygroup/myproject:ref_type:branch:ref:main:environment:production
3. If environment is protected, append environment name and protected flag: ``project_path:mygroup/myproject:ref_type:branch:ref:main:environment:production:environment_protected:true`

Proposal 3: Allow input of sub variable (should not be implemented)

Proposal 2: Allow input of sub variable based on this proposal here.

job_name:
  secrets:
    CI_JOB_JWT: # or any other variable name
      id-token:
        sub: "..." # string

*This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.*