Merge branch '17227-upcoming-milestone-is-confusing-when-projects-have-different-milestones' into 'master'

Make upcoming milestone work across projects

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 #17227.

See merge request !4125

Merge branch '13691-allow-admin-to-reset-user-password-and-force-password-reset-on-next-login' into 'master'

Force password change after admin reset

Closes #13691.

See merge request !4016

Added authentication service for docker registry

This adds a simple authentication service for docker which uses current user credentials to authenticate pulls and pushes.

I have only one concern. Since the `.docker/config` is unencrypted, thus the password for user stored there is unencrypted, maybe we should from the start implement function to generate/provide a separate password just for the purposes of accessing docker registry?

What do you think @jacobvosmaer @sytses @marin?

cc @marin 

See merge request !3787

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

- Don't do setup in spec bodies.
- Don't `describe` a symbol.
- Don't use 'should'.

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.

Add cache count metrics to rails cache

See merge request !4157

Change colors for charcoal and graphite sidebar themes
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

cc @skyruler @jschatz1 

See merge request !4149

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

Refactor diff notes

Related to https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4101

/cc @rspeicher 

See merge request !4110