This was needed for a transition phase only. For details see #45389.

Closes #45389.

We request Gitaly in a N+1 manner to build discussion diffs. Once the diffs are from different revisions, it's hard to make a single request to the service in order to build the whole response.
With this change we solve this problem and simplify a lot fetching this piece of info.

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

This can occur when a note is added to a commit and then this commit
is deleted.

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

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

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

Closes #32258.

It was using name, instead of username. Fixes documentation as well

Closes #46454

This reverts commit 2ebafdfb

When displaying the pipelines of a project we now preload the following
data:

1. Authors of the commits that belong to these pipelines
2. The number of warnings per pipeline, which is used by
   Ci::Pipeline#has_warnings?

== Commit Authors

Previously this data was queried for every Commit separately, leading to
20 SQL queries being executed in the worst case. With an average of 3 to
5 milliseconds per SQL query this could result in 100 milliseconds being
spent in _just_ getting Commit authors.

To preload this data Commit#author now uses BatchLoader (through
Commit#lazy_author), and a separate module
Gitlab::Ci::Pipeline::Preloader is used to ensure all authors are loaded
before they are used.

== Number of warnings

This changes Ci::Pipeline#has_warnings? so it supports preloading of the
number of warnings per pipeline. This removes the need for executing a
COUNT(*) query for every pipeline just to see if it has any warnings or
not.

Old behavior of creating TODO when
“Merge When Pipeline Succeeds” service fails, is generalized to:

Create a TODO whenever MR became unmergeable
(and similar to notification, MR author and merge_user are both applicable)

Display MR unmergeable reasons

For notifying via todo or email.

First, transitions between can_be_merged & cannot_be_merged are removed,
as they are currently blocked in `check_if_can_be_merged`.
`can_be_merge` always returns to `unchecked` first,
before it can transition to `cannot_be_merged` (and vice versa).

We want to avoid repeated notification triggered by repeated transition
between `cannot_be_merged` & `unchecked`.

So we added `cannot_be_merged_recheck` state, similar to `unchecked`,
but as a mean to remember it’s from cannot_be_merged.

See https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18042/#note_65945407

Since `unchecked` and `cannot_be_merged_recheck` both mean
“we are in the middle of checking if it is mergeable”,
quite often we need to see if merge_status is in either one of them,
so `check_state?` is added to achieve this.

This reverts commit 4e1bb1d1.

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