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

- added suggestions to mock data
- fixed props to be not required

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.

Scoped labels in EE require additional changes in CE code.

Also removes specs related to the flag

- concerns
- dashboard
- groups
- import

When executing quick actions, this limits the `commands_changes`
response to only those used by the frontend

Move this to EE-only. It isn't useful here since there's only one board

Move common functionality to BoardsActions concern

This style change enforces `return if ...` instead of
`return nil if ...` to save maintainers a few minor review points

Fix misspellings in app/spec comments

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

Ability to filter confidential issues

Closes #50747

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

This reverts commit 9202bbd1, reversing
changes made to 4b282e9c.

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

Signed-off-by: NTakuya Noguchi <takninnovationresearch@gmail.com>

Removes unneeded params from permitted list

This also fixes commenting on commits with a hash starting with a large
number

Use internally only boolean params.

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

Due to a regression in
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/24919,
Content-Disposition is hard-coded to `attachment` instead of `inline`.
We now use the argument `disposition` to fix that problem.

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/57660

Cookies are no longer needed for this feature to work.

In order to have an accurate date about the last activity of a User
we need to update the last_activity_on field when the User is visiting
some basic pages of GitLab like pages related to Dashboards, Projects,
Issues and Merge Requests

Users downloading non-ASCII attachments would see garbled characters.
When used with object storage, AWS S3 would return an InvalidArgument
error: Header value cannot be represented using ISO-8859-1.

Per RFC 5987 and RFC 6266, Content-Disposition should be encoded
properly. This commit takes the Rails 6 implementation of
ActiveSuppport::Http::ContentDisposition
(https://github.com/rails/rails/pull/33829) and ports it here.

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/47673

This engine was replaced with CommonMarker in 11.4, it was deprecated
since then.

receive data on when there is a conflict

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

Also removed unnecessary comment