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

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 #15638

stub Devise.omniauth_providers to return GitHub even if the gitlab.yml has no omniauth provider enabled
This will fix failing tests in case gitlab.yml file has no omniauth providers enabled

`User#starred_projects` doesn't perform any visibility checks. This has
a couple of problems:

1. It assumes a user can always view all of their starred projects in
   perpetuity (project not changed to private, access revoked, etc.).
2. It assumes that we'll only ever allow a user to star a project they
   can view. This is currently the case, but bugs happen.

Add `User#viewable_starred_projects` to filter the starred projects by
those the user either has explicit access to, or are public or
internal. Then use that in all places where we list the user's starred
projects.

This reverts commit 4cc85a58, reversing
changes made to 90ae445b.
Signed-off-by: NRémy Coutable <remy@rymai.me>

In 8278b763 the default behaviour of annotation
has changes, which was causing a lot of noise in diffs. We decided in #17382
that it is better to get rid of the whole annotate gem, and instead let people
look at schema.rb for the columns in a table.

Fixes: #17382

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

Use Rugged's TagCollection#create instead of gitlab-shell's Repository#add_tag for better performance
Signed-off-by: NRémy Coutable <remy@rymai.me>

This changes Project#protected_branch? to use a query to check if a
branch is protected, instead of loading all ProtectedBranch records into
memory just to check if the list of names includes a given branch name.

This is a combination of 3 commits.

- Update the bare repositories info/attributes if the default branch is updated
- Check the diff attributes of a file before showing a diff
- Update CHANGELOG

- Parameter validation as ISO8601 format

This status will be returned only when there are no failed jobs
that are not allowed to fail.

"CHANGELOG", "NEWS", "HISTORY", and "CHANGES" are recognized as Changelog files.

Also adds relevant tests for each of these names.

Resolves #14864.

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

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