And add tests

Issues
https://gitlab.com/gitlab-org/gitlab-ce/issues/47149
https://gitlab.com/gitlab-org/gitlab-ce/issues/56014

Cached markdown version is composed both from global and local
markdown version. This allows admins to bump version locally when
needed (e.g. when external URL is changed).

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

LFS uploads are handled in concert by workhorse and rails. In normal
use, workhorse:

* Authorizes the request with rails (upload_authorize)
* Handles the upload of the file to a tempfile - disk or object storage
* Validates the file size and contents
* Hands off to rails to complete the upload (upload_finalize)

In `upload_finalize`, the LFS object is linked to the project. As LFS
objects are deduplicated across all projects, it may already exist. If
not, the temporary file is copied to the correct place, and will be
used by all future LFS objects with the same OID.

Workhorse uses the Content-Type of the request to decide to follow this
routine, as the URLs are ambiguous. If the Content-Type is anything but
"application/octet-stream", the request is proxied directly to rails,
on the assumption that this is a normal file edit request. If it's an
actual LFS request with a different content-type, however, it is routed
to the Rails `upload_finalize` action, which treats it as an LFS upload
just as it would a workhorse-modified request.

The outcome is that users can upload LFS objects that don't match the
declared size or OID. They can also create links to LFS objects they
don't really own, allowing them to read the contents of files if they
know just the size or OID.

We can close this hole by requiring requests to `upload_finalize` to be
sourced from Workhorse. The mechanism to do this already exists.

It was leaings confidential issue titles and MR titles to any users

Fix spec

Fix spec

Fix tests

This includes a set of APIs to manipulate container registry.
This includes also an ability to delete tags based on requested
criteria, like keep-last-n, matching-name, older-than.

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

Check if `X-Forwarded-For` is set before getting the IP of the request,
with this the real IP address of the runner is shown if it's behind a
proxy.

closes https://gitlab.com/gitlab-org/gitlab-ce/issues/53676

LFS uploads are handled in concert by workhorse and rails. In normal
use, workhorse:

* Authorizes the request with rails (upload_authorize)
* Handles the upload of the file to a tempfile - disk or object storage
* Validates the file size and contents
* Hands off to rails to complete the upload (upload_finalize)

In `upload_finalize`, the LFS object is linked to the project. As LFS
objects are deduplicated across all projects, it may already exist. If
not, the temporary file is copied to the correct place, and will be
used by all future LFS objects with the same OID.

Workhorse uses the Content-Type of the request to decide to follow this
routine, as the URLs are ambiguous. If the Content-Type is anything but
"application/octet-stream", the request is proxied directly to rails,
on the assumption that this is a normal file edit request. If it's an
actual LFS request with a different content-type, however, it is routed
to the Rails `upload_finalize` action, which treats it as an LFS upload
just as it would a workhorse-modified request.

The outcome is that users can upload LFS objects that don't match the
declared size or OID. They can also create links to LFS objects they
don't really own, allowing them to read the contents of files if they
know just the size or OID.

We can close this hole by requiring requests to `upload_finalize` to be
sourced from Workhorse. The mechanism to do this already exists.

including refactoring, disabling sourcepos for pipelines that
don't need it, and minimizing spec changes by disabling
sourcepos when not testing for it explicitly.

This adds 'data-sourcepos' to tags, indicating which
line of markdown it came from.  Sets the stage for
intelligently manipulating specific lines of markdown.

In https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15475/diffs, a
significant amount of work went into eliminating N+1 queries in the
/api/groups/:id/projects endpoint. We can reuse the
`Entities::Project.prepare_relation` call on the projects.

In a group with 2,573 projects on GitLab.com, this change significantly
improves performance:

* 18019 SQL queries down to 21
* Time spent in DB: 70 s down to 384 ms

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

Currently if a project is inside a nested group and a user doesn't have
specific permissions for that group but does have permissions on a
parent group the `GET /projects/:id` API call will return the following
permissions:

```json
permissions: { project_access: null, group_access: null }
```

It could also happen that the group specific permissions are of lower
level than the ones the user has in parent groups. This patch makes it
so that the permission returned for `group_access` is the highest from
amongst the hierarchy, which is (ostensibly) the information that the
API user is interested in for that field.

For features the feature gates are sometimes projects, not groups or
users. For example for git object pools:
https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/5872

This commit allows for setting feature group gates based on projects, by its
path as that seems most convenient.

We introduced releases_page feature flag.
Given this feature is deemed stable, we should remove
this flag before 19th.