Allow users to create pipelines for merge requests in the target project if the user has permission

NOTE: This feature is behind a feature flag ci_allow_to_create_merge_request_pipelines_in_target_project and it's disabled by default. We do NOT enable it until frontend part is done, which makes the security implication explicit.

What does this MR do?

This MR introduces a backend changes for #217451 (closed).

Currently, when a pipeline is triggered for merge request, the pipeline is always created in the source project. This is a problematic when a target project's member wants to verify a fork MR in target project's CI settings, because there are no ways to create a pipeline in the target project.

We allow the pipeline triggerer to create a pipeline in the target project if the actor has permission. For example, a developer in the target project can create a pipeline in the project, therefore s/he can create trigger a pipeline for merge request in the target project's context.

If the actor doesn't have permission, the process falls back to the current one, which is creating a pipeline in the source project always. Therefore, a malicious actor cannot abuse this feature for creating a pipeline in the parent project for stealing secrets, etc.

This feature only works for Pipelines for merge requests, Pipelines for merged results and Merge Train. It does not work for branch pipelines.

Related #217451 (closed)

Use cases

Mainly, there are two use cases

1. Private fork project members can run CI in the parent project seamlessly.
2. Open source project members can verify fork MRs in parent project's CI settings.

Manual QA

• Case: There is an open source project and has a fork MR
  • Case: When a parent project's member clicks "Run Pipeline" button in MR
    • Expected: a merged result pipeline is created in the target project.
    • Result: PASS
  • Case: When an external contributor clicks "Run Pipeline" button in MR
    • Expected: a detached merge request pipeline is created in the source project.
    • Result: PASS
  • Case: When a parent project's member adds the MR to merge trains
    • Expected: a merge train pipeline is created in the parent project and the fork MR is merged.
    • Result: PASS
• Case: There is a private project and has a fork MR
  • Case: When a project's member clicks "Run Pipeline" button in MR
    • Expected: the pipeline is created in the parent project.
    • Result: PASS
  • Case: When a project's member pushes a new commit to the MR
    • Expected: a merged result pipeline is created in the parent project.
    • Result: PASS

Screenshots

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team