Implement pipelines for merged results in `gitlab-org/gitlab` pipeline

Objective

Reduce the number of broken masters due to branches which were behind master and have a successful MR pipeline but fail in master.

Proposal

Steps taken from https://gitlab.com/gitlab-org/quality/team-tasks/issues/195#note_279239095

• Enable disable_merge_trains feature flag. e.g. /chatops run feature set disable_merge_trains --project=gitlab-org/gitlab true => Done on 2020-02-17.
• Add documentation guidance for steps Maintainers will need to do (tentative date: 2020-02-18):
  • Maintainer runs an extra pipeline via "Merge Request tab > Run Pipeline button" and set MWPS. This means the pipeline result is based on the latest master even though the feature branch is behind some commits.
  • Forked pipeline workflow can follow the current workflow of merging.
  • !25449 (merged) and gitlab-com/www-gitlab-com!41397 (merged)
• Ask current maintainers for feedback (tentative date: 2020-02-24)
• Communicate broadly (tentative date: 2020-02-26):
  • Company call
  • Eng. week-in-review
  • Slack: #development, #backend, #frontend, #quality, #backend_maintainers, #frontend_maintainers, #ux_maintainers
• Enable "Merge pipelines will try to validate the post-merge result prior to merging" (Settings > General > Merge Request) (tentative date: 2020-02-27)

Advantages:

• Authors won't have to rebase their branch as frequently anymore (basically, only when there are conflicts) since the Merge Results pipeline will already incorporate the latest changes from master. This should result in faster review/merge cycles since maintainers won't have to ask for a final rebase: instead, they'll only have to start a MR pipeline and set MWPS.
• This step should bring us very close to the actual Merge Trains feature by testing the Merge Results against the latest master at the time of the pipeline creation.

Disadvantages:

• Starting a MR pipeline before merging will increase the review/merge cycle time by a pipeline's duration.
• This will result in more Git refs (the merge refs) and more pipelines.

Considerations

• Will this prevent merging if master is currently broken?
  • If maintainers start a MR pipeline + MWPS, yes it should prevent any merges into master until master is fixed (although, we don't enforce green pipelines as a condition to be able to merge (this is tracked at https://gitlab.com/gitlab-org/quality/team-tasks/issues/326).
• Will this feature prevent a merge if the pipeline is has a transient/flaky failure?
  • Yes, but the problem can already occurs currently, and retrying the failing job usually solves it.