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 :100:, 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`.

Reject slug+uri concat if slug is deemed unsafe

See merge request gitlab/gitlabhq!3108

Fix url redaction for issue links

See merge request gitlab/gitlabhq!3091

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.

No leading/trailing spaces when generating heading ids (Fixes #57528)

Closes #57528

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

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