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.

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

Treat empty markdown and html strings as valid cached text, not missing cache that needs to be updated

Instead of using the factories. Since the factories might be using
columns that aren't available in the schema at version the particular
spec is running in.

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

- Create MemberPresenter alongside with GroupMemberPresenter and ProjectMemberPresenter
- Make Member model Presentable
- Move action_member_permission from MembersHelper into the MemberPresenter
- Added rspec using double, separate specs for GroupMemberPresenter and ProjectMemberPresenter

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

remove_column should only be used in the up (or change) step of a migration if
it's a post-deployment migration. Otherwise there will be downtime due to the
ActiveRecord column cache, which we can avoid by using the IgnorableColumn
concern in combination with a post-deployment migration.