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

The ApplicationSetting model uses the CacheMarkdownField concern, which updates
the cached HTML when the field is updated in the database. However, in specs,
when we want to test conditions using ApplicationSetting, we stub it, because
this is accessed in different ways throughout the application.

This means that if a spec runs that caches one of the Markdown fields, and a
later spec uses `stub_application_setting` to set the raw value of that field,
the cached value was still the original one. We can work around this by ignoring
the Markdown cache in contexts where we're using `stub_application_setting`.

We could be smarter, and only do this on the Markdown fields of the model, but
this is probably fine.

#38869

This does two things:
- Pass commit oids instead of `Gitlab::Git::Commit`s. We only need the
former.
- Depend on only the target repository for conflict listing. For
conflict resolution, treat one repository as a remote one so that we can
implement it as such in Gitaly.

By importing this Ruby code into gitlab-rails (and gitaly-ruby), we avoid
200ms of startup time for each gitlab_projects subprocess we are eliminating.

By not having a gitlab_projects subprocess between gitlab-rails / sidekiq and
any git subprocesses (e.g. for fork_project, fetch_remote, etc, calls), we can
also manage these git processes more cleanly, and avoid sending SIGKILL to them

I've followed the [upgrade guide](https://github.com/thoughtbot/factory_bot/blob/4-9-0-stable/UPGRADE_FROM_FACTORY_GIRL.md) and ran these two commands:

```
grep -e FactoryGirl **/*.rake **/*.rb -s -l | xargs sed -i "" "s|FactoryGirl|FactoryBot|"
grep -e factory_girl **/*.rake **/*.rb -s -l | xargs sed -i "" "s|factory_girl|factory_bot|"
```
Signed-off-by: NRémy Coutable <remy@rymai.me>

The hook ordering influenced the diffs being generated as these used
values from before the update due to the memoization still being in
place. This commit reorders them and tests against this behaviour.

When a note is part of a discussion, the email sent out will be
`In-Reply-To` the previous note in that discussion. It also
`References` all the previous notes in that discussion, and the
original issue.

Closes gitlab-org/gitlab-ce#36054.

When a note is part of a discussion, the email sent out should be
`In-Reply-To` the previous note in that discussion.

Closes gitlab-org/gitlab-ce#36054

Allows ordering in GET api/v4/projects/:project_id/repository/contributors
through `order_by` and `sort` params.
The available `order_by` options are: name|email|commits.
The available `sort` options are: asc|desc.

Closes gitaly#808

This allows us to avoid relying on telnet / netcat being installed

In CE, this does nothing - the `MergeRequests::BuildService` will, at the time
of writing, never return a description for this case.

In EE, a project can have a default MR template, which will be returned by the
service. Previously we were only using the description passed in the params,
ignoring any already set on the object. Now we fall back to the one set on the
object if there was none in the params, allowing quick actions to be executed
from default MR templates when creating an MR from an issue.

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

Changed file icons already addressed in
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15367

i.e.
Using compare and swap we update the expires_at value.
The thread that actually is able to update this value will also set
the cache holding method_call enabled state

Signed-off-by: NRémy Coutable <remy@rymai.me>

The Gitaly CommitService is being hammered by n + 1 calls, mostly when
finding commits. This leads to this gRPC being turned of on production:
https://gitlab.com/gitlab-org/gitaly/issues/514#note_48991378

Hunting down where it came from, most of them were due to
MergeRequest#show. To prove this, I set a script to request the
MergeRequest#show page 50 times. The GDK was being scraped by
Prometheus, where we have metrics on controller#action and their Gitaly
calls performed. On both occations I've restarted the full GDK so all
caches had to be rebuild.

Current master, 806a68a8, needed 435 requests
After this commit, 154 requests