doc: Explain why we're using mirrors for downstream pipelines

Signed-off-by: Rémy Coutable <remy@rymai.me>

doc/development/testing_guide/end_to_end/index.md

@@ -94,6 +94,19 @@ subgraph "`gitlab-org/gitlab-qa-mirror` pipeline"
 Please note, we plan to [add more specific information](https://gitlab.com/gitlab-org/quality/team-tasks/-/issues/156)
 about the tests included in each job/scenario that runs in `gitlab-org/gitlab-qa-mirror`.
 
+NOTE:
+You may have noticed that we use `gitlab-org/build/omnibus-gitlab-mirror` instead of
+`gitlab-org/omnibus-gitlab`, and `gitlab-org/gitlab-qa-mirror` instead of `gitlab-org/gitlab-qa`.
+This is due to technical limitations in the GitLab permission model: the ability to run a pipeline
+against a protected branch is controlled by the ability to push/merge to this branch.
+This means that for developers to be able to trigger a pipeline for the default branch in
+`gitlab-org/omnibus-gitlab`/`gitlab-org/gitlab-qa`, they would need to have Maintainer permission in those projects.
+For security reasons and implications, we couldn't open up the default branch to all the Developers.
+Hence we created these mirrors where Developers and Maintainers are allowed to push/merge to the default branch.
+This problem was discovered in <https://gitlab.com/gitlab-org/gitlab-qa/-/issues/63#note_107175160> and the "mirror"
+work-around was suggested in <https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4717>.
+A feature proposal to segregate access control regarding running pipelines from ability to push/merge was also created at <https://gitlab.com/gitlab-org/gitlab/-/issues/24585>.
+
 #### With Pipeline for Merged Results
 
 In a Pipeline for Merged Results, the pipeline runs on a new ref that contains the merge result of the source and target branch.