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

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

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.

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.

Personal snippet uploads have neither a group nor a project. If a GitLab
instance were configured with a relative URL root (e.g. `/gitlab`), then
the Markdown filter would not include this root in the generated path.
We fix this by adding this root if there is no group or project.

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

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

Excludes a few filters that require more work:

* lib/banzai/filter/image_lazy_load_filter_spec.rb
* lib/banzai/filter/syntax_highlight_filter_spec.rb
* lib/banzai/filter/table_of_contents_filter_spec.rb

Part of #47424

There are certain inputs that look like valid URIs that are accepted by URI
but not Addressable::URI. Handle the case where the latter fails.

Closes #41442

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

Avoid multi-line ?: (the ternary operator). Use if/unless instead.

See #17478

    A lot of git operations were being repeated, for example, to build a url
    you would ask if the path was a Tree, which would call a recursive routine
    in Gitlab::Git::Tree#where, then ask if the path was a Blob, which would
    call a recursive routine at Gitlab::Git::Blob#find, making reference to
    the same git objects several times. Now we call Rugged::Tree#path, which
    allows us to determine the type of the path in one pass.

    Some other minor improvement added, like saving commonly used references
    instead of calculating them each time.

We're trying to avoid circular dependency errors.

Prior, if we were viewing a blob at
`https://example.com/namespace/project/blob/master/doc/some-file.md` and
it contained a relative link such as `[README](../README.md)`, the
resulting link when viewing the blob would be:
`https://example.com/namespace/project/blob/README.md` which omits the
`master` ref, resulting in a 404.

to the default branch, not to master