Use merge train to sync changes back to canonical

What does this MR do and why?

Updates codebase to use the merge-train when syncing security changes back to canonical after the security release is out. Two modifications were made:

• The Security::SyncRemotesService was updated to ignore the GitLab project if a feature flag is enabled
• The security template was updated with indications to kick the merge-tran pipeline.

This approach is a bit manual but it should be updated in upcoming iterations.

Related to gitlab-com/gl-infra/delivery#19402 (closed)

Template example

Click to expand

Final steps

• Sync default branches for GitLab Foss, Omnibus GitLab and Gitaly, via ChatOps:

  # In Slack
  /chatops run release sync_remotes --security

• Sync the GitLab default branch by using the merge-train project:

  • Disable the gitlab-org/gitlab@master -> gitlab-org/security/gitlab@master pipeline schedule on the merge-train.
  • Trigger the gitlab-org/security/gitlab@master -> gitlab-org/gitlab@master pipeline schedule on the merge-train and wait until it finishes. This pipeline will attempt to sync the GitLab default branch.
  • If the sync fails, repeat the above step.

• If after 5 times the sync by the merge train continues to fail, use the previous strategy to sync the GitLab project:

  • Disable the merge_train_to_canonical feature flag on ops.
  • Enable the gitlab-org/gitlab@master -> gitlab-org/security/gitlab@master pipeline schedule on the merge-train.
  • Execute the sync_remotes task on Slack: /chatops run release sync_remotes --security. In this case, if the sync fails, a merge request will be created and release manager intervention will be required.

• Verify all remotes are synced:

  # In Slack
  /chatops run mirror status

  If conflicts are found, manual intervention will be needed to sync the repositories.

Author Check-list

• [-] Has documentation been updated?