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

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

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

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

See merge request gitlab/gitlabhq!2583

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.

This refactors the Markdown pipeline so it supports the rendering of
multiple documents that may belong to different projects. An example of
where this happens is when displaying the event feed of a group. In this
case we retrieve events for all projects in the group. Previously we
would group events per project and render these chunks separately, but
this would result in many SQL queries being executed. By extending the
Markdown pipeline to support this out of the box we can drastically
reduce the number of SQL queries.

To achieve this we introduce a new object to the pipeline:
Banzai::RenderContext. This object simply wraps two other objects: an
optional Project instance, and an optional User instance. On its own
this wouldn't be very helpful, but a RenderContext can also be used to
associate HTML documents with specific Project instances. This work is
done in Banzai::ObjectRenderer and allows us to reuse as many queries
(and results) as possible.

Rails 5.0 requires to explicitly permit attributes when building a URL
using current `params` object.

The `safe_params` helper allows developers to just call `safe_params.merge(...)`
instead of manually adding `permit` to every call.

https://github.com/rails/rails/pull/20868

Previously, these wouldn't count issues or MRs in subgroups - meaning that if
_this_ group had no issues or MRs, we'd show the empty state, which was wrong.

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

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

This changes various controllers to use the new EventCollection class
for retrieving events. This class uses a JOIN LATERAL query on
PostgreSQL to retrieve queries in a more efficient way, while falling
back to a simpler / less efficient query for MySQL.

The EventCollection class also includes a limit on the number of events
to display to prevent malicious users from cycling through all events,
as doing so could put a lot of pressure on the database.

JOIN LATERAL is only supported on PostgreSQL starting with version 9.3.0
and as such this optimisation is only used when using PostgreSQL 9.3 or
newer.

Add a rubocop rule to check if a method 'redirect_to' is used without explicitly set 'status' in 'destroy' actions of controllers

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 `/…`.