Over a year ago, through e0824f17367a44e5bac84dac7197f9b45e37ab01, the
hooks in this repository were updated to not be successful, basically
block each push from happening.

This change removes the hooks, and updates the documentation. There's no
customer impact, and these changes are just part of a general cleanup.

Fix SAST and Dependency Scanning

See merge request gitlab-org/gitlab-shell!410

Use docker image for Code Intelligence

See merge request gitlab-org/gitlab-shell!409

Release v13.7.0

See merge request gitlab-org/gitlab-shell!408

Fix gitlab-shell not handling relative URLs over UNIX sockets

See merge request gitlab-org/gitlab-shell!406

From
https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4498#note_397401883,
if you specify a relative path such as:

```
external_url 'http://gitlab.example.com/gitlab'
```

gitlab-shell doesn't have a way to pass the `/gitlab` to the host. For example, let's say we have:

```
gitlab_url: "http+unix://%2Fvar%2Fopt%2Fgitlab%2Fgitlab-workhorse%2Fsocket"
```

If we have `/gitlab` as the relative path, how do we specify what is the
UNIX socket path and what is the relative path? If we specify:

```
gitlab_url: "http+unix:///var/opt/gitlab/gitlab-workhorse.socket/gitlab
```

This is ambiguous. Is the socket in
`/var/opt/gitlab/gitlab-workhorse.socket/gitlab` or in
`/var/opt/gitlab/gitlab-workhorse.socket`?

To fix this, this merge request adds an optional
`gitlab_relative_url_root` config parameter:

```
gitlab_url: "http+unix://%2Fvar%2Fopt%2Fgitlab%2Fgitlab-workhorse%2Fsocket"
gitlab_relative_url_root: /gitlab
```

This is only used with UNIX domain sockets to disambiguate the socket
and base URL path. If `gitlab_url` uses `http://` or `https://`, then
`gitlab_relative_url_root` is ignored.

Relates to https://gitlab.com/gitlab-org/gitlab-shell/-/issues/476

Release v13.6.0

See merge request gitlab-org/gitlab-shell!407