Give gitlab-org/gitlab pipelines the ability to generate helm values file for component versions

The release-environments repository is responsible for actually deploying or upgrading our environments to a new version.

This means the pipelines that run in gitlab-org/gitlab to deploy to release environments need to interface with this repository.

In the past we typically interface with deployment repositories by triggering a child pipeline and passing in what version to deploy as one or more variables (which become environment variables in the deploy pipeline).

This model unfortunately has a lot of problems with declarative infrastructure patterns like Kubernetes, and the release-environments repository has been designed to be purely declarative from the ground up.

Updated solution

While the original solution focused on a purely declarative approach and essentially automating the MR process, this didn't have the best experience for developers following the pipelines. As a first iteration in order to make things look "the most comfortable" for developers while still maintaining a gitops approach as much as possible, we will instead go back to using trigger pipelines and variables from the gitlab-org/gitlab repo to the release-environments repo. However, the release-environments repo will detect it's being called by a trigger, and "commit back" the changes to the git repo as part of the deploy process. If a deploy fails, the change won't be committed, so other deployments can continue.

In a future iteration we will improve upon this.

Original solution

What this means is that ideally instead of the traditional pattern of triggering a pipeline and passing variables, we want to have a job in the gitlab-org/gitlab pipeline that can ideally do the following

1. Identify the right environment to deploy to (probably from branch name). e.g. branch 15-7-stable-ee will deploy to release environment 15-7-stable (we could even make the environment have ee in the name to keep them identical)
2. Identify the right environment file in the release-environments repository for the environment in question (e.g. environments/15-7-stable/environment.yaml
3. Modify the versions.components part of the yaml file to set the new version of all the components being deployed. These image tags will be from what is built using #2674 (closed). Note the structure below which comes from the GitLab helm chart itself
4. Open a merge request in the release-environments repository with the changes to the environment file in question as part of the merge request. The comment on the merge request should have a link to the gitlab-org/gitlab pipeline it's coming from
5. Set the MR to "merge when pipeline succeeds"
6. Wait until the MR is merged, the merge train passes, and there is a pipeline on main with the MR in question
7. If possible, attach the pipeline running on main as a child pipeline to the gitlab-org/gitlab pipeline

install_type: helm
cluster: release-gitlab-gke
versions:
  chart: 2c53f5a64653af20e903c43a0ed26780c587cf30
  components: # Modify section from here
    gitlab:
      gitlab-shell:
        image:
          tag: "v15.7.5"
      gitlab-pages:
        image:
          tag: "v15.7.5"
      kas:
        image:
          tag: "v15.7.5"
    global:
      gitlabVersion: "15.7.5"
    registry:
      image:
        tag: "v15.7.5"