ci: let danger-review fail in the community fork

What does this MR do?

As asked in #171 (note), this lets danger-review fail without blocking in merge request pipelines that run in the community fork, gitlab-community/gitlab-org/labkit. It is meant as the interim step until the fork has credentials of its own (note), which stays tracked in #171.

danger-review comes from the common-ci-tasks danger component and reads its token from Vault, and the fork has no credentials for it. In a pipeline that runs there the job fails, and because it is not allowed to fail, the pipeline fails with it.

Related to #171

How

The job's rules are overridden with two rules:

1. A merge request pipeline whose CI_PROJECT_PATH is exactly gitlab-community/gitlab-org/labkit runs the job with allow_failure: true.
2. Every other merge request pipeline gets the component's own rule, unchanged, so this project, personal forks and any other project keep a blocking danger-review. The rule is the same in common-ci-tasks v5.40, which !720 moves to.

A rule-level allow_failure only applies when its rule matches. I matched the exact project path, rather than comparing the merge request's source and target projects, so that nothing changes in pipelines that run in this project. If the fork is ever renamed or moved, the first rule stops matching and the job blocks again.

What it leaves as it is

A pipeline that runs in this project for a merge request from the fork still runs danger-review as a blocking job, and as #171 describes, Vault refuses it there because the ID token names the fork as the project. That covers the pipeline a maintainer runs from the merge request and, going by GitLab's code rather than a pipeline I have seen, the merge train. If you would rather cover those too until the credentials are in place, the first rule can also match the source project:

    - if: $CI_PIPELINE_SOURCE == "merge_request_event" && ($CI_PROJECT_PATH == "gitlab-community/gitlab-org/labkit" || $CI_MERGE_REQUEST_SOURCE_PROJECT_PATH == "gitlab-community/gitlab-org/labkit")

I kept this MR to the fork's own pipelines, as asked.

How I checked it

I ran the committed .gitlab-ci.yml through a local GitLab 19.5.0 (EE, unlicensed, since only EE parses secrets:) with common-ci-tasks v5.23, autolabels, modular-feature-testing and the markdownlint component mirrored into it, a fork at gitlab-community/gitlab-org/labkit, a personal fork, and a contributor who is a member of the community fork only. GitLab created these merge request pipelines and set allow_failure on danger-review as follows:

Merge request from	Pipeline runs in	Before	After
a branch of gitlab-org/labkit	gitlab-org/labkit	false	false
the community fork	gitlab-community/gitlab-org/labkit	false	true
the community fork	gitlab-org/labkit, run by a member	false	false
a personal fork	the personal fork	false	false

A branch pipeline with no merge request has no danger-review job, before and after, and CI lint finds the file valid in each project. With the source project line above, the third row becomes true and the others stay as they are. yamllint with the project's .yamllint.yaml and editorconfig-checker pass on the file, and commitlint with the project's config passes on the commit.

This MR's own pipeline runs in the community fork with the change, so danger-review should end there as a warning. I expect conformance-spec to fail in it, since the labkit-spec pipeline is created as me and I can't run pipelines in that project. That would be the same for any merge request from the fork that changes v2/ or .gitlab-ci.yml (point 2 of #171), and it does not come from this change. A pipeline run in this project for this MR would still fail on danger-review, as described above.