We had similar code in a few places to redirect to the last page if
the given page number is out of range. This unifies the handling in a
new controller concern and adds usage of it in all snippet listings.

Sorting preference functionality has been extracted
from `IssuableCollections` to a new `SortingPreference`
concern in order to reuse this functionality in projects
(and groups in the future).

Count issues related merge requests based on user access level. And
issue can have related MRs from projects where user does not have
access so the number of related merge requests should be adjusted
based on user's ability to access the related MRs.

https://gitlab.com/gitlab-org/gitlab-ce/issues/59581

- adding a "Manual" option to the dropdown
- show 100 issues list when manually sorting

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

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.

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.

Add a new search bar filter for confidential issues. Add filtering
support to the IssuesFinder.

In order to let users' sorting preferences transfer between devices, we
save the preference for issues and MRs (one preference for issues, one
for MRs) in the backend inside the UserPreference object

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.

Enables frozen string for the following:

* app/controllers/*.rb
* app/controllers/admin/**/*.rb
* app/controllers/boards/**/*.rb
* app/controllers/ci/**/*.rb
* app/controllers/concerns/**/*.rb

Partially addresses #47424.

This whitelists all existing offenses for the various CodeReuse cops, of
which most are triggered by the CodeReuse/ActiveRecord cop.

Closes #49120

When filtering issues with a search string in a group, we observed on GitLab.com
that Postgres was using an inefficient query plan, preferring the (global)
trigram indexes on description and title, rather than using a filter on the
restricted set of issues within the group.

Change the callers of the IssuableFinder to use a CTE in this case to fence the
rest of the query from the LIKE filters, so that the optimiser is forced to
perform the filter in the order we prefer.

This will only force the use of a CTE when:

1. The use_cte_for_search params is truthy.
2. We are using Postgres.
3. We have passed the `search` param.

The third item is important - searching issues using the search box does not use
the finder in this way, but contructs a query and appends `full_search` to
that. For some reason, this query does not suffer from the same issue.

Currenly, we only pass this param when filtering issuables (issues or MRs) in a
group context.

We had `item_project_ids` to help make slow queries on the dashboard faster, but
this isn't necessary any more - the queries are plenty fast, and we forbid
searching the dashboard without filters.

This commits replaces `params` with `safe_params` in `url_for` helpers
to resolve security issues [1] and failing specs with the

```
ArgumentError:
  Attempting to generate a URL from non-sanitized request parameters!
  An attacker can inject malicious data into the generated URL, such as
  changing the host. Whitelist and sanitize passed parameters to be secure.
```

error.

[1]: https://gitlab.com/gitlab-org/gitlab-ce/issues/45168

In some situations (listing labels for epics) we want to
list only group ancestor labels, this is already supported
in LabelsFinder we just need to enable additional parameters.

Also `set_issuables_index` method now loads project labels only if
@Project is set (which is not used for epic group labels).

By extracting a new `filter_items` method, we can override that in the
IssuesFinder and MergeRequestsFinder separately, so we don't need checks that
the model is the correct one, because we can just use the class we're in to know
that.

We can do the same for the VALID_PARAMS constant, by making it a class method.

On epics roadmap page we list all epics in the given time frame
without pagination (at least for the first iteration), in this
case it would be nice to use the existing issuables index logic
except pagination (see MR gitlab-ee!4281). For this reason this
patch allows to easily disable pagination.

Related gitlab-ee!4281

Compared to the merge_request_diff association:

1. It's simpler to query. The query uses a foreign key to the
   merge_request_diffs table, so no ordering is necessary.
2. It's faster for preloading. The merge_request_diff association has to load
   every diff for the MRs in the set, then discard all but the most recent for
   each. This association means that Rails can just query for N diffs from N
   MRs.
3. It's more complicated to update. This is a bidirectional foreign key, so we
   need to update two tables when adding a diff record. This also means we need
   to handle this as a special case when importing a GitLab project.

There is some juggling with this association in the merge request model:

* `MergeRequest#latest_merge_request_diff` is _always_ the latest diff.
* `MergeRequest#merge_request_diff` reuses
  `MergeRequest#latest_merge_request_diff` unless:
    * Arguments are passed. These are typically to force-reload the association.
    * It doesn't exist. That means we might be trying to implicitly create a
      diff. This only seems to happen in specs.
    * The association is already loaded. This is important for the reasons
      explained in the comment, which I'll reiterate here: if we a) load a
      non-latest diff, then b) get its `merge_request`, then c) get that MR's
      `merge_request_diff`, we should get the diff we loaded in c), even though
      that's not the latest diff.

Basically, `MergeRequest#merge_request_diff` is the latest diff in most cases,
but not quite all.

And use .rubocop.yml to exclude paths we don't care,
rather than using the cop itself to exclude.

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