Allow id_tokens to be configured as file type variables

What does this MR do and why?

The id_tokens key in .gitlab-ci.yml file allows to define one or more JWT tokens that will be created with the defined aud claim and provided to the job as a regular variable.

Until now the type of the variable was not controlled and it was always a "variable" type. For example, with configuration like:

job:
  id_tokens:
    MY_TOKEN:
      aud: some-aud
  script:
    - echo $MY_TOKEN

a new JWT for MY_TOKEN would be generated and send to the GitLab Runner with the job payload. In the job execution the value of this token would be available directly as the value of MY_TOKEN environment variable.

While that works, in some cases we may want to put the value of the token in a file pointed by a variable.

In case of the example above, if we would need to have the token present in a file (that next some tool will consume), we would need to create such file manually, for example as:

job:
  id_tokens:
    MY_TOKEN:
      aud: some-aud
  variables:
    MY_TOKEN_FILE: "${CI_PROJECT_DIR}.tmp/MY_TOKEN"
  script:
    - echo $MY_TOKEN > "${MY_TOKEN_FILE}"
    - custom-tool --token-file "${MY_TOKEN_FILE}" run

While this works, it's a hack. And in GitLab CI/CD we have a native way to mark a variable to be a "file" type variable.

The type can be configured for variables defined in the UI. It's also configurable for the variables crated for secrets. With the change here, we can now do the same for id_tokens. The example above can be now simplified to:

job:
  id_tokens:
    MY_TOKEN_FILE:
      aud: some-aud
      file: true
  script:
    - custom-tool --token-file "${MY_TOKEN_FILE}" run

With this GitLab Runner will create the file based variable that will be pointed by MY_TOKEN_FILE environment variable - all of that happens now natively as for any other file variable defined in GitLab.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

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.