Add a supporting code to separate groups#show
and groups#details which is required for the
proper implementation of the Group Overview
content and Security Dashboard option for it

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.

Updates specs to use new rails5 format.

The old format:
`get :show, { some: params }, { some: headers }`

The new format:
`get :show, params: { some: params }, headers: { some: headers }`

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.

[master] Resolve "Personal access token with only `read_user` scope can be used to authenticate any web request"

See merge request gitlab/gitlabhq!2583

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.

The group activity feed was limited to the first 20 projects found
in the group, which caused activity from some projects to be omitted.
A limit of 20 is applied to the query for events, so the
extra pagination does little in the way of performance.

Closes #42560

And several other failures

When projects were listed after groups, the projects that would also
have been listed on the last page containing groups would be repeated.

When filtering we want all to preload all the ancestors upto the specified
parent group.

- root
  - subgroup
    - nested-group
      - project

So when searching 'project', on the 'subgroup' page we want to preload
'nested-group' but not 'subgroup' or 'root'

And fix some pagination bugs

By preloading the count of members, projects and subgroups of a group,
we don't need to query them later.

We also preload the entire hierarchy for a search result and include
the counts so we don't need to query for them again

And document what extra queries are still being performed.

When fetching children for a group with a filter, we will search all
nested groups for results and render them in an expanded tree

When a user is authorized to a group, they are also authorized to see all the
ancestor groups and descendant groups.

When a user is authorized to a project, they are authorized to see all the
ancestor groups too.

Closes #32135

See merge request !11764

In order to avoid string manipulation or modify route params (to make them unambiguous for `url_for`), we are accepting a behavior change:

When being redirected to the canonical path for a group, if you requested a group show path starting with `/groups/…` then you’ll now be redirected to the group at root `/…`.

Don’t replace a substring of the path if it is part of the top level route.

E.g. When redirecting from `/groups/ups` to `/groups/foo`, be careful not to do `/grofoo/ups`.

Projects are unaffected by this issue, but I am grouping the `#ensure_canonical_path` tests similar to the group and user tests.