Fix permissions check in `RelativeLinkFilter`

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

When post-processing relative links to absolute links
RelativeLinkFilter didn't take into consideration that
internal repository data could be exposed for users
that do not have repository access to the project.

This commit solves that by checking whether the user
can `download_code` at this repository, avoiding any
processing of this filter if the user can't.

Additionally, if we're processing for a group (
no project was given), we check if the user can
read it in order to expand the href as an extra.
That doesn't seem necessarily a breach now,
but an extra check doesn't hurt as after all
the user needs to be able to `read_group`.

When we un-escape HTML text to find references in it, we should then
re-escape the whole text again, not only found matches.

Because we replace matches with milestone/label links (which contain
HTML tags we don't want to escape again), we re-escape HTML text
with placeholders instead of these links and then replace placeholders
in the escaped text.

User images and videos will get proxied through
the Camo server in order to keep malicious
sites from collecting the IP address of users.

https://gitlab.com/gitlab-org/gitlab-ce/issues/62971

Adds support for embedding specific charts from the
metrics dashboard. Expected parameters are dashboard,
title, group, and y_label.

Removes the feature flag that controls whether
metrics dashboard urls unfurl the metrics dashboard
charts.

Squash this commit and reword before merging..

The SanitizationFilter was running before the WikiFilter. Since
WikiFilter can modify links, we could see links that _should_ be stopped
by SanatizationFilter being rendered on the page. I (kerrizor) had
previously addressed the bug in: https://gitlab.com/gitlab-org/gitlab-ee/commit/7bc971915bbeadb950bb0e1f13510bf3038229a4
However, an additional exploit was discovered after that was merged.
Working through the issue, we couldn't simply shuffle the order of
filters, due to some implicit assumptions about the order of filters, so
instead we've extracted the logic that sanitizes a Nokogiri-generated
Node object, and applied it to the WikiLinkFilter as well.

On moving filters around:
Once we start moving around filters, we get cascading failures; fix one,
another one crops up. Many of the existing filters in the WikiPipeline
chain seem to assume that other filters have already done their work,
and thus operate on a "transform anything that's left" basis;
WikiFilter, for instance, assumes any link it finds in the markdown
should be prepended with the wiki_base_path.. but if it does that, it
also turns `href="@user"` into `href="/path/to/wiki/@user"`, which the
UserReferenceFilter doesn't see as a user reference it needs to
transform into a user profile link. This is true for all the reference
filters in the WikiPipeline.

Convert several occurrences of `map` + `flatten` to
`flat_map` where applicable.

When cache_collection_render runs we end up reading and writing
things to redis even if we already have the rendered field cached
in the DB. This commit avoids using redis at all whenever we have
the field already rendered in the DB cache.

Adds GFM Pipline filters to insert a placeholder in the generated
HTML from GFM based on the presence of a metrics dashboard link.

The front end should look for the class 'js-render-metrics' to
determine if it should replace the element with metrics charts.
The data element 'data-dashboard-url' should be the endpoint
the front end should hit in order to obtain a dashboard layout
in order to appropriately render the charts.

Prior to https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/29889,
only the project context were set for the Markdown renderer. For a note
on an issuable, the group context was set to `nil` because
`note.noteable.try(:group)` attempted to get the issuable's group, which
doesn't exist.

To make group notifications work, now both the project and group context
are set. The context gets passed to `RelativeLinkFilter`, which
previously assumed that it wasn't possible to have both a group and a
project in the Markdown context. However, if a group were defined, it
would take precedence, and the URL rendered for uploads would be
`/group/-/uploads` instead of `/group/project/uploads/`. This led to
404s in e-mails.

However, now that we have both project and group in the context, we
render the Markdown giving priority to the project context if is set.

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

If we put the emoji filter before the reference filters, each emoji will
have a wrapper element that prevents the reference filter from detecting
the presence of the emoji.

As the emoji filter now runs after the reference filters, references
must contain a literal emoji, not the GitLab Flavored Markdown
versions (:100`, for example).

A weird side-effect is that if you have a label with the 100 emoji, and
a label named 💯, then trying to reference the latter will work (link
to the correct label), but will render with the 100 emoji. I'm
comfortable with that edge case, I think.

This allows using `CacheMarkdownField` for models that are not backed
by ActiveRecord.

When the including class inherits `ActiveRecord::Base` we include
`Gitlab::MarkdownCache::ActiveRecord::Extension`. This will cause the
markdown fields to be rendered and the generated HTML stored in a
`<field>_html` attribute on the record. We also store the version
used for generating the markdown.

All other classes that include this model will include the
`Gitlab::MarkdownCache::Redis::Extension`. This add the `<field>_html`
attributes to that model and will generate the html in them. The
generated HTML will be cached in redis under the key
`markdown_cache:<class>:<id>`. The class this included in must
therefore respond to `id`.

First reported:
  https://gitlab.com/gitlab-org/gitlab-ce/issues/60143

When the page slug is "javascript:" and we attempt to link to a relative
path (using `.` or `..`) the code will concatenate the slug and the uri.
This MR adds a guard to that concat step that will return `nil` if the
incoming slug matches against any of the "unsafe" slug regexes;
currently this is only for the slug "javascript:" but can be extended if
needed. Manually tested against a non-exhaustive list from OWASP of
common javascript XSS exploits that have to to with mangling the
"javascript:" method, and all are caught by this change or by existing
code that ingests the user-specified slug.

When a milestone name contained an HTML entity that would be escaped (&,
<, >), then it wasn't possible to refer to this milestone by name, or
use it in a quick action.

This already worked for labels, but not for milestones. We take care to
re-escape un-matched milestones, too.

Add changelog entry

Add missing href to all redactor specs and removed href assignment

Remove obsolete spec

If original_content is given, it should be used for link content

When rendering a label we want to check 'scoped_label' feature
availability on a project/group where label is being used. For
this reason a label presenter is used in UI and information about
context project/group is passed to this presenter.

Change based on comments in MR #27025

Update based on comments in MR #27025

That's a straightforward feature flag code removal for 11.10

To make sure all known issues are linked to the correct epic, I've gone
through the code base, and updated the comments where required.

Backports https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10161
(code out of ee/ folder).

Replaces blockquote fences with \n,
keeping the line numbering intact.

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

Scoped labels in EE require additional changes in CE code.

Adds the groundwork needed in order to persist multi-line suggestions,
while providing the parsing strategy which will be reused for the
**Preview** as well.

- Show pipeline status, title, MR Status and project path
- Popover attached to gitlab flavored markdown everywhere, including:
  + MR/Issue Title
  + MR/Issue description
  + MR/Issue comments
  + Rendered markdown files

Implements the filtering logic for
`suggestion:-x+y` syntax.

Prior to this change, 35 Gitaly RPCs were allowed. But recently there's
been a renewed interest in performance. By lowering the number of
calls new N + 1's will pop up.

Later commits will add blocks to ignore the raised errors, followed by
an issue for each to be fixed.