We had timeouts during the upload of the artifacts
so I increase it to 90 minutes.

Since the changes of 939ade2b we observe
that pipelines are executed on non-protected branches, which is not what
we want.

GitLab's documentation was a bit unclear on the according CI variables
CI_COMMIT_REF_PROTECTED and CI_MERGE_REQUEST_TARGET_BRANCH_PROTECTED, as
stated in this stack overflow answer:
https://stackoverflow.com/a/59023344/3018229

We need to explicitly check for the variable values to be "true" instead
of just checking whether they are set.

Previously we had the master branch hard-coded in a variable in order to
determine whether to run the integration pipeline (on non-master branch)
or the merge pipeline (on master branch). This variable had to be
adapted everytime we copy a branch, which can potentially be forgotten
and lead to problems.

Remove the hard-coded branch and use the branch protection state for
this decision instead in order to make this more flexible.

The rules for the yamllint jobs have been defined in the .yamllint class
before. They were overridden in the manifest pipeline's yamllint job,
though, which has its own rules, so we don't need them to be inherited
in this case. And in the manifest integration pipeline the rules can be
much easier, so define them there instead of at the class-level.

Usually project name and path are identical after project creation. It
is possible, though, to change the name of a project without changing
its path.
When triggering a pipeline on the integration branch, we are using the
CI_PROJECT_NAME variable to reference the project. Unexpectedly, this
variable contains the *path*, not the *name* of the project (see
https://gitlab.com/gitlab-org/gitlab/-/issues/20030).
Hence we have to use the project path in all other places where the
integration branch name is constructed in our Python code.

This will make the manifest project support the "skip build" label.

This reverts commit 4db257d3.

It does not work on the manifest, because we do not run merge request
pipelines there, so CI_MERGE_REQUEST_LABELS is not set at all.

GitLab API has changed:
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/94164/diffs#diff-content-c201dae00b72426693ddcb40edf6005e7702e935

Instead of hard-coding the project list in the changelog generator
script, make them passable via arguments. This way we can have different
changelogs in different envrionments. Hence we're adding the changelog
job in the ci-test environment as well.

This case should trigger a new pipeline instead of reporting an error.

This fixes older releases not appearing in the changelog.

Refactor three scripts into one in order to support triggering a new
pipeline in the case of a skipped MR pipeline. This was not possible to
implement with the previous three-script design. The single scripts
were not used in other places anyway.

The dynamic job was only necessary because GitLab did not expand
variables in the "trigger:project" keyword:
https://gitlab.com/gitlab-org/gitlab/-/issues/347469

This has been fixed in GitLab 15.3, so we don't need it anymore:
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/92346

Everytime we push a new commit to a branch, a new pipeline is created.
Often the pipeline for the previous commit has not finished yet, and
GitLab does not automatically cancel it. It consumes valuable build
time, even if we don't need the results anymore.
Adding a MR pipeline job to search for previous pipelines on the same
branch and cancel them explicitly.

For a given project all artifacts may be deleted. This was needed due to
space limitations on the gitlab server.

Otherwise the parent pipeline is stuck in "running" state until the
manual action has been performed. See for reference:
https://gitlab.com/gitlab-org/gitlab/-/issues/361574