We dropped MySQL support and a lot of mysql specific code has been
removed in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/29608.

This comes in from the other direction and removes any `if postgresql?`
branches.

These are not required because MySQL is not
supported anymore

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

Removed the conditions added to
Project.with_feature_available_for_user, and moved to the
IssuableFinder. Now, we ensure that, in the projects retrieved
in the Finder, the user has enough access for the feature.

Move Contribution Analytics related spec in spec/features/groups/group_page_with_external_authorization_service_spec to EE

Backports https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10161
(code out of ee/ folder).

This reverts merge request !26823

Move Contribution Analytics related spec in spec/features/groups/group_page_with_external_authorization_service_spec to EE

When we use the `search` param on an `IssuableFinder`, we can run into
issues. We have trigram indexes to support these searches. On
GitLab.com, we often see Postgres's optimiser prioritise the (global)
trigram indexes over the index on `project_id`. For group and project
searches, we know that it will be quicker to filter by `project_id`
first, as it returns fewer rows in most cases.

For group issues search, we ran into this issue previously, and went
through the following iterations:

1. Use a CTE on the project IDs as an optimisation fence. This prevents
   the planner from disregarding the index on `project_id`.
   Unfortunately it breaks some types of sorting, like priority and
   popularity, as they sort on a joined table.
2. Use a subquery for listing issues, and a CTE for counts. The subquery
   - in the case of group lists - didn't help as much as the CTE, but
   was faster than not including it. We can safely use a CTE for counts
   as they don't have sorting.

Now, however, we're seeing the same issue in a project context. The
subquery doesn't help at all there (it would only return one row, after
all). In an attempt to keep total code complexity under control, this
commit removes the subquery optimisation and applies the CTE
optimisation only for sorts we know that are safe.

This means that for more complicated sorts (like priority and
popularity), the search will continue to be very slow. If this is a
high-priority issue, we can consider introducing further optimisations,
but this finder is already very complicated and additional complexity
has a cost.

The group CTE optimisation is controlled by the same feature flag as
before, `attempt_group_search_optimizations`, which is enabled by
default. The new project CTE optimisation is controlled by a new feature
flag, `attempt_project_search_optimizations`, which is disabled by
default.

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

The Upcoming milestone filter only considers active milestones, but the
Started one included closed milestones, too. This was inconsistent.

Since the CTE is faster than a subquery and the only reason we're using
a subquery is that the CTE can't handle sorting by certain attributes,
let's use the CTE always (when the feature flag is enabled) when
counting, since we can ignore ordering if we just want a count of
results.

Ability to filter confidential issues

Closes #50747

See merge request gitlab-org/gitlab-ce!24960

This reverts commit d133bf84, reversing
changes made to 7981c029.

Use internally only boolean params.

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

We already had a flag to use a CTE, but this broke searching in some
cases where we need to sort by a joined table. Disabling the CTE flag
makes searches much slower.

The new flag, to use a subquery, makes them slightly slower than the
CTE, while maintaining correctness. If both it and the CTE flag are
enabled, the subquery takes precedence.

By using the parameters `?labels=None|Any` the user can filter
issues/mrs from the API that has `none/any` label.

Affected endpoints are:

- /api/issues
- /api/projects/:id/issues
- /api/groups/:id/issues
- /api/merge_requests
- /api/projects/:id/merge_requests
- /api/groups/:id/merge_requests

In GET `api/v4/projects/:id/issues` the user can filter issues
that have an assigned milestone through the parameter
`milestone=Any+Milestone`.

Deprecate corresponding dash versions created-by-me and assigned-to-me

This changes the issue and MR index pages so the pagination system
re-uses the output of the COUNT(*) query used to calculate the number of
rows per state (opened, closed, etc). This removes the need for an
additional COUNT(*) on both pages.

When we are filtering by a single project, and the current user has access to
see confidential issues on that project, we don't need to filter by
confidentiality at all - just as if the user were an admin.

The filter by confidentiality often picks a non-optimal query plan: for
instance, AND-ing the results of all issues in the project (a relatively small
set), and all issues in the states requested (a huge set), rather than just
starting small and winnowing further.