This change fixes a bug that prevents projects being
imported when there are diff notes present in merge requests.

Solves https://gitlab.com/gitlab-org/gitlab-ce/issues/63955

Today, Pipelines for merge train run on `refs/merge`,
however, this causes a race condition that it can be
overwritten by CheckMergeabilityService.

This patch fixes the problem by generating `refs/train`
for those pipelines.

This MR introduces tracking of the `rebase_jid` for merge requests. As
with `merge_ongoing?`, `rebase_in_progress?` will now return true if a
rebase is proceeding in sidekiq.

After one release, we should remove the Gitaly-based lookup of rebases.
It is much better to track this kind of thing via the database.

When a user sets only_allow_merge_if_pipeline_succeeds, also named
as "Pipeline must succeed" project setting, we require the pipeline
to be present.

This solves race condition issues especially with external CI
providers when a build is triggered externally but no pipelines are
created in GitLab yet.

Document that a head pipeline is expected when using "Pipeline
must succeed" setting. Also explain limitations with the use of
only/except where there may not be any jobs created and the merge
request will not be allowed to be merged.

This couples the code that transitions the `MergeRequest#merge_status`
and refs/merge-requests/:iid/merge ref update.

In general, instead of directly telling `MergeToRefService` to update
the merge ref, we should rely on `MergeabilityCheckService` to keep
both the merge status and merge ref synced. Now, if the merge_status is
`can_be_merged` it means the merge-ref is also updated to the latest.

We've also updated the logic to be more systematic and less user-based.

It abstracts some codes for common methods in AutoMerge::*Services.

We have one auto merge strategy today - Merge When Pipeline
Succeeds.

In order to add more strategies for Merge Train feature,
we abstract the architecture to be more extensible.

Removed arguments

Fix spec

This introduces payload to the ServiceResponse with
the merge ref HEAD commit data

This couples the code that transitions the `MergeRequest#merge_status`
and refs/merge-requests/:iid/merge ref update.

In general, instead of directly telling `MergeToRefService` to update
the merge ref, we should rely on `MergeabilityCheckService` to keep
both the merge status and merge ref synced. Now, if the merge_status is
`can_be_merged` it means the merge-ref is also updated to the latest.

We've also updated the logic to be more systematic and less user-based.

Starting with Rails 5, belongs_to now adds a presence validation to the
association, and so as of shoulda-matchers 4.0.0 the belong_to matcher
follows suit and tests that this validation is there by setting the
association to nil and asserting that there are validation errors. This
exposed an error with the `validate_branches` method: we need to check
the source and target project exist.

Refactor

Prevents refspec as branch name, which would bypass branch protection
when used in conjunction with rebase.

HEAD seems to be a special case with lots of occurrence,
so it is considered valid for now.

Another special case is `refs/head/*`, which can be imported.

Due to the nature of pipelines for merge requests, deployments.ref can
be a merge request ref instead of a branch name.

We support the environment auto-stop hook for this case

Model.new.attributes now also returns encrypted attributes.

This backports the changes from
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10452

Backports https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10161
(code out of ee/ folder).

Author and committers approvals are split in EE
This commit provides backports for those changes

This reverts commit 886f00bc.

and add spec

Add changelog

ok

ok

By using `refs/merge-requests/:iid/head`

ok

ok

Improve naming nicely

Add nice tests

add nice tests

fix some more

revert

Adds the groundwork needed in order to persist multi-line suggestions,
while providing the parsing strategy which will be reused for the
**Preview** as well.

This will be further required for supporting multi-assignees MRs

This commit updates the pipeline block that appears on the merge request
page to include information that will be exposed by the API as part of
the post-merge pipeline feature.

Make it sane

Include merge ref head

Fix union

Improve a bit

Add spec

remove

add spec

Add changelog

fix coding offence

Apply suggestion to spec/models/merge_request_spec.rb

ok

ok

Fix

Fix spec

Fix spec

fix

Simplify the things

Memoize

OK

a

By preloading associations and batching issuable metadata lookups,
we can significantly cut the number of SQL queries needed to load
the Todos API endpoint.

On GitLab.com, my own tests showed my user's SQL queries went
from 365 to under 60 SQL queries.

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/40378

Conflicts:
  doc/ci/variables/README.md
  spec/models/ci/pipeline_spec.rb

Adds the ground work for writing into
the merge ref refs/merge-requests/:iid/merge the
merge result between source and target branches of
a MR, without further side-effects such as
mailing, MR updates and target branch changes.

This backports the changes made in EE to fix merge request approvers
from https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9574.