Create ID token variables and pass one to the runner

What does this MR do and why?

This is the 2nd MR for #356986 (closed).

This MR makes 3 changes:

• It defines custom JWT variables for CI builds that have ID tokens configured
• When the project CI/CD setting opt_in_jwt is true (it is false by default), it does not define default JWT variables for CI builds
• When the project CI/CD setting opt_in_jwt is true and ID tokens are configured, it uses the first ID token to authenticate with Hashicorp Vault when fetching secrets adds functionality to generate variables with JWT values for each ID token configured for a CI build.

Screenshots or screen recordings

We have a Hashicorp Vault with an authentication configuration that responds to an audience of developers (see bound_audiences)

By default and before this MR, a GitLab instance uses its own base URL as the audience claim for a JWT: https://gitlab.com/gitlab-org/gitlab/-/blob/20482887faa40ea8abd155a52651eb99a57bab80/lib/gitlab/ci/jwt_v2.rb#L12

So when we have a job configured to fetch a secret from the Vault

test_secrets:
  variables:
    VAULT_AUTH_PATH: gitlab
    VAULT_AUTH_ROLE: gitlab-test-role
    VAULT_SERVER_URL: http://172.16.123.1:8200
  secrets:
    DATABASE_PASSWORD:
      vault: gitlab-test/db/password    
  script:
    - echo $DATABASE_PASSWORD
    - cat $DATABASE_PASSWORD

The job fails

It won't be possible to configure a job with an ID token that has the right audience until the next MR for this feature, so for now we will update the job's ID tokens in the console

When we retry the job, it succeeds!

How to set up and validate locally

It's quite complicated to test this locally, so reviewers are not expected to test functionality that communicates with Vault until #369351 (closed) is completed

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.