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

This reverts commit cb10b725c8929b8b4460f89c9d96c773af39ba6b.

This was wrong when there were over 100 files in the diff, because we
did not use the same diff options as subclasses of
`Gitlab::Diff::FileCollection::Base` when getting the raw diffs. (The
reason we don't use those classes directly is because they may perform
highlighting, which isn't needed for just counting the diffs.)

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Remove MergeRequest#closes_issue?; Remove the default parameter value for #cache_merge_request_closes_issues! and #issues_mentioned_but_not_closing