This reverts merge request !3647

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

Closes #3055

These methods seems to be unused.
Signed-off-by: NRémy Coutable <remy@rymai.me>

`Gitlab::Git::Compare` will already have the correct order; sorting in
Ruby can only ruin that. (The correct order being the same as `git log`
- reverse chronological while maintaining the commit graph.)

As an example, imagine a branch where someone has their system clock set
wrong for some of the commits. Not only will those commits be in the
wrong order - which is maybe reasonable - but sorting in Ruby can also
put commits with the same timestamp out of order, as Ruby's sorting
isn't stable.

Signed-off-by: NJeroen van Baarsen <jeroenvanbaarsen@gmail.com>

When a build fails for a commit, create a todo for the author of the
merge request that commit is the HEAD of. If the commit isn't the HEAD
commit of any MR, don't do anything. If there already is a todo for that
user and MR, don't do anything.

Current limitations:
- This isn't configurable by project.
- The author of a merge request might not be the person who pushed the
  breaking commit.

Remove unused methods from Event model

Given an activity feed entry like:

> Douwe Maan commented on [issue #123] at [gitlab-org/gitlab-ce]

...the `issue #123` link will now have a `title` attribute.

Postgres only needs to select a single column, so that can used as a
sub-query where `Milestone.upcoming_ids_by_projects` is actually used in
`IssuableFinder`.

MySQL needs to select the `due_date` column because it's used in the
`HAVING` clause, so it has to return an array of IDs.

Before: we took the next milestone due across all projects in the
search and found issues whose milestone title matched that
one. Problems:

1. The milestone could be closed.
2. Different projects have milestones with different schedules.
3. Different projects have milestones with different titles.
4. Different projects can have milestones with different schedules, but
   the _same_ title. That means we could show issues from a past
   milestone, or one that's far in the future.

After: gather the ID of the next milestone on each project we're looking
at, and find issues with those milestone IDs. Problems:

1. For a lot of projects, this can return a lot of IDs.
2. The SQL query has to be different between Postgres and MySQL, because
   MySQL is much more lenient with HAVING: as well as the columns
   appearing in GROUP BY or in aggregate clauses, MySQL allows them to
   appear in the SELECT list (un-aggregated).

Closes #17537