We don't think this is needed any more - see
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21521, and
https://gitlab.com/gitlab-org/gitlab-ce/issues/52271 for removing the flag.

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

Partially addresses #47424.

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

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.

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

This removes the extra check for project-ids which is not needed at all.
This does not necessarily reduce execution time of the query, but
improves planning time by a few millseconds.

Closes #37125.

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.

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

Signed-off-by: NRémy Coutable <remy@rymai.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.

We're going to cache the total open count separately, and then just perform
these counts on the list. We already do that to get the pagination information,
through Kaminari, and a future change will make Kaminari reuse the query results
from earlier in the request.

Having two states that essentially mean the same thing is very much like
having a boolean "true" and boolean "mostly-true": it's rather silly.
This commit merges the "reopened" state into the "opened" state while
taking care of system notes still showing messages along the lines of
"Alice reopened this issue".

A big benefit from having only two states (opened and closed) is that
indexing and querying becomes simpler and more performant. For example,
to get all the opened queries we no longer have to query both states:

    SELECT *
    FROM issues
    WHERE project_id = 2
    AND state IN ('opened', 'reopened');

Instead we can query a single state directly, which can be much faster:

    SELECT *
    FROM issues
    WHERE project_id = 2
    AND state = 'opened';

Further, only having two states makes indexing easier as we will only
ever filter (and thus scan an index) using a single value. Partial
indexes could help but aren't supported on MySQL, complicating the
development process and not being helpful for MySQL.

Allow issues filtering on `author_id` and `assignee_id`.

When an issuable's state changes, or one is created, we should clear the cache
counts for a user's assigned issuables, and also the project-wide caches for
this user type.

We were including controller params in the cache key, so the key for the header
didn't match the one for the list itself!

These cache a hash of counts by state, so the state isn't needed in the key
itself.