These are the structural changes for supporting the EE feature of moving
"code_owner_approval_required" state from existing on a project to being
on the protected branches individually, allowing for CODEOWNER
validation on push events.

This commit adds pipeline.type key to PipelineEntity.
This key will be used in MR widget in the next iteration.

Prior to 12.1, rebase status was looked up directly from Gitaly. In
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14417 , a DB
column was added to track the status instead. However, we couldn't stop
looking at the gitaly status immediately, since some rebases may been
running across the upgrade.

Now that we're in 12.3, it is safe to remove the direct-to-gitaly
lookup. This also happens to fix a 500 error that is seen when viewing
an MR for a fork where the source project has been removed.

We still look at the Gitaly status in the service, just in case Gitaly
and Sidekiq get out of sync - I assume this is possible, and it's a
relatively cheap check.

Since we atomically check and set `merge_requests.rebase_jid`, we
should never enqueue two `RebaseWorker` jobs in parallel.

Splits auto-refreshing of MR widget into 2 requests:

- the one which uses etag-caching and invalidates the fields on change
- the one without caching

The idea is to gradually move all the fields to etag-cached endpoint

- Original EE MR: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14827

Concurrent calls to UserMergeToRef RPC updating a single ref
can lead to an opaque fail that is being rescued at Gitaly.

So this commit adds an exclusive lease to the mergeability
check process with the key as the current MR ID.

We dropped MySQL support and a lot of mysql specific code has been
removed in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/29608.

This comes in from the other direction and removes any `if postgresql?`
branches.

Next models are affected:
* Project
* Namespace
* Issue
* Merge request
* CI Trigger
* CI Pipeline schedule
Signed-off-by: NDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

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