Previously, when the wiki page format was anything other than `markdown`
or `asciidoc` the formatted content would be returned though a Gitaly
call. Gitaly in turn would delegate formatting to the gitlab-gollum-lib
gem, which in turn would delegate that to various gems (like RDoc for
`rdoc`) and then apply some very liberal sanitization.

It was too liberal!

This change brings our wiki content formatting in line with how we
format other markdown at GitLab, so we have a SSOT for sanitization.

https://gitlab.com/gitlab-org/gitlab/issues/30540

Fixes RelativeLinkFilter for users that don't have access
to the project's repository

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

`simple_format` is not defined in ActionView::Helpers::TagHelper, but
it is actually located in ActionView::Helpers::TextHelper.

The solution is to include the correct helper.

I've also added tests for `#markup_unsafe` because they were missing.

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

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

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

By default, we now strip images in the 'first_line_in_markdown'
method.  This keeps images from being displayed in the
one-liner of both todo and project activity panels.

Although not currently used, we allow images to be preserved
with the allow_images: true options.

Because the post-processing of the rendered README is dependent on the
context (i.e. the current user), do the post-processing when the
README is being displayed.