[.gitlab-ci.yml] in OCaml: translate [latest_release] pipeline

Context

Builds upon !10948 (merged). Translates the (very small) latest_release pipeline.

Stack

1. !11999 (merged) (add ci/lib_gitlab_ci). Look here for rationale.
2. !12000 (merged) (add ci/bin)
3. !10948 (merged) (translate .gitlab-ci.yml)
4. !11461 (merged) (translate latest_release pipeline) <- You are here
5. !11500 (merged) (translate *release_tag(test) pipelines)
6. !11501 (merged) (translate master_branch pipeline)
7. !11534 (closed) (translate schedule_extended_test pipeline)
8. !11671 (closed) (translate before_merging pipeline)

Manually testing the MR

This MR rewrites the latest_release pipeline in OCaml-in-CI. You can check that this MR introduces no semantic changes to the configuration using GitLab CI Inspector. The easiest way to use is through the tezos/tezos-specific docker image. Set up an alias like:

alias gci-tezos="docker run --tty --volume $(pwd):$(pwd) --workdir $(pwd) --env GCI_GL_ACCESS_TOKEN='...' registry.gitlab.com/nomadic-labs/gitlab-ci-inspector/tezos "

(setting GCI_GL_ACCESS_TOKEN is only necessary if you want to lint YAML against the GitLab API)

You can now use the included utility diff-full-config to see the diff between two merged configurations (includes and templates inlined) in a given environment (environments correspond roughly to pipeline types). The basic invocation is:

gci-tezos diff-full-config COMMIT1 COMMIT2 ENVIRONMENT

So do e.g.

gci-tezos diff-full-config origin/arvid@gitlab-ci.yml-in-ocaml HEAD latest_release

with this MR checked out to see the differences between origin/arvid@gitlab-ci.yml-in-ocaml and the tip of this branch in the latest_release environment. If everything is well, there should be no output.

You can verify that, in fact, this MR introduces no changes to any environment by changing latest_release to all-envs in the above command:

gci-tezos diff-full-config origin/arvid@gitlab-ci.yml-in-ocaml HEAD all-envs

Again, the output is empty.

If you're of the paranoid inclination, then you can also spawn an artificial latest_release pipeline with the following command:

gci-tezos run-pipeline --gl-access-token glpat-... --env latest_release

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR