This is an ID-less table with just three columns: an association to the merge
request diff the commit belongs to, the relative order of the commit within the
merge request diff, and the commit SHA itself.

Previously we stored much more information about the commits, so that we could
display them even when they were deleted from the repo. Since 8.0, we ensure
that those commits are kept around for as long as the target repo itself is, so
we don't need to duplicate that data in the database.

This cop has been renamed to ActiveRecordSerialize to match the way
"ActiveRecord" is usually written.

This is allowed for existing instances so we don't end up 76 offenses
right away, but for new code one should _only_ use this if they _have_
to remove non database data. Even then it's usually better to do this in
a service class as this gives you more control over how to remove the
data (e.g. in bulk).

This removes the need for relying on Rails' "dependent" option for data
removal, which is _incredibly_ slow (even when using :delete_all) when
deleting large amounts of data. This also ensures data consistency is
enforced on DB level and not on application level (something Rails is
really bad at).

This commit also includes various migrations to add foreign keys to
tables that eventually point to "projects" to ensure no rows get
orphaned upon removing a project.

Closes #34052

To make it simpler to assign users to an Issuable, make MergeRequest
support the attribute `assignee_ids`.

Fix https://gitlab.com/gitlab-org/gitlab-ce/issues/27070

Deprecate "chat commands" in favor of "slash commands"

We looked for things like:

 - `slash commmand`
 - `slash_command`
 - `slash-command`
 - `SlashCommand`

This Cop blacklists the use of ActiveRecord's "serialize" method, except
for cases where we already use this.

I don't know why this happens exactly, but given an upstream and fork repository
from a customer, both of which required GC, resolving conflicts would corrupt
the fork so badly that it couldn't be cloned.

This isn't a perfect fix for that case, because the MR may still need to be
merged manually, but it does ensure that the repository is at least usable.

My best guess is that when we generate the index for the conflict
resolution (which we previously did in the target project), we obtain a
reference to an OID that doesn't exist in the source, even though we already
fetch the refs from the target into the source.

Explicitly setting the source project as the place to get the merge index from
seems to prevent repository corruption in this way.

The problem is that we often go via a diff object constructed from the diffs
stored in the DB. Those diffs, by definition, don't overflow, so we don't have
access to the 'correct' `real_size` - that is stored on the MR diff object
iself.

This reverts merge request !10076

See https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9245

 Rename column in the database
 Rename fields related to import/export feature
 Rename API endpoints
 Rename documentation links
 Rename the rest of occurrences in the code
 Replace the images that contain the words "build succeeds" and docs referencing to them
 Make sure pipeline is green and nothing is missing.

updated doc images

renamed only_allow_merge_if_build_succeeds in projects and fixed references

more updates

fix some spec failures

fix rubocop offences

fix v3 api spec

fix MR  specs

fixed issues with partials

fix MR spec

fix alignment

add missing v3 to v4 doc

wip - refactor v3 endpoints

fix specs

fix a few typos

fix project specs

copy entities fully to V3

fix  entity error

more fixes

fix failing specs

fixed missing entities in V3 API

remove comment

updated code based on feedback

typo

fix spec

Previously, we created an unmergeable todo when a merge request:

1. Had merge when pipeline succeeds set.
2. Became unmergeable.

However, when merge when pipeline succeeds fails due to unmergeability,
the flag isn't actually removed. And a merge request can become
unmergeable multiple times, as every time the target branch is updated
we need to re-check the mergeable status. This means that if the todo
was marked done, and the MR was checked again, a new todo would be
created for the same event.

Instead of checking this, we should create the todo from the service
responsible for merging when the pipeline succeeds. That way the todo is
guaranteed to only be created when we care about it.

This reverts commit e00fb2bdc2090e9cabeb1eb35a2672a882cc96e9.

# Conflicts:
#	.rubocop.yml
#	.rubocop_todo.yml
#	lib/gitlab/ci/config/entry/global.rb
#	lib/gitlab/ci/config/entry/jobs.rb
#	spec/lib/gitlab/ci/config/entry/factory_spec.rb
#	spec/lib/gitlab/ci/config/entry/global_spec.rb
#	spec/lib/gitlab/ci/config/entry/job_spec.rb
#	spec/lib/gitlab/ci/status/build/factory_spec.rb
#	spec/lib/gitlab/incoming_email_spec.rb