It's possible to construct a commit graph where the output of `git log`
isn't in timestamp order. Grouping the commits in the list by date then
gives dramatically wrong results. Instead, go for the more pragmatic
approach: use the commits in the order they're given, and just show the
date line each time the date changes. This means that the same date
header can show up multiple times, but at least the ordering is
preserved.

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

[ci skip]
Signed-off-by: Rémy Coutable <remy@rymai.me>

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

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).

When an admin changes a user's password for them, force the user to
reset the password after logging in by expiring the new password
immediately.

As discussed in #15667.

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

Closes #15638

[ci skip]

and drop exception handling around HealthCheck::Utils.process_checks, it wasn't needed

The ForksController enforces this, so don't show the link if it won't go
anywhere.

Because method call timings are inclusive (that is, they include the
time of any sub method calls) this would lead to the total method
execution time often being far greater than the total transaction time.
Because this is incredibly confusing it's best to simply _not_ track the
total method execution time, after all it's not that useful to begin
with.

Fixes gitlab-org/gitlab-ce#17239

Allow Admins to remove the Login with buttons for OAuth services and still be able to import on the changelog

[ci skip]

`Time#to_date` just takes the (timezone-less) year, date, and month, and
creates a new date from that. Because the commits in the list are
grouped by date, rather than chunked when the date changes, a commit can
be shown in the wrong order if its CommitDate has a timezone-less date
that's different to other commits around it.

Convert all CommitDates to the server timezone before grouping, as that
will at least produce consistent results. Users can still see a
timestamp on the commit that doesn't match the date it's grouped under,
because the timestamp shown uses the user's local timezone, and the
grouping uses the server's timezone, but that was an issue anyway.