While testing
https://gitlab.com/gitlab-org/build/CNG/-/merge_requests/1062, we
found `make install` was not copying the right binaries, such as
`gitlab-shell-authorized-keys-check`.

This might have originally been written with a single binary in mind
(https://gitlab.com/gitlab-org/gitlab-shell/-/issues/207).

Changelog: fixed

New version of LabKit provides FIPS checks that we can use instead
of the custom code

This commit adds support of using a FIPS-validated SSL library with
compiled Go executables when `FIPS_MODE=1 make` is run. A Go compiler
that supports BoringSSL either directly (e.g. the `dev.boringcrypto`
branch) or with a dynamically linked OpenSSL
(e.g. https://github.com/golang-fips/go) is required.

This is similar to the changes to support FIPS in GitLab Runner and in
GitLab Pages:
https://gitlab.com/gitlab-org/gitlab-pages/-/merge_requests/716

Changelog: added

If git is not available or gitlab-shell is not built in a repository, it falls back the VERSION file. That command is not properly escaped and results in the message:

> awk: cmd. line:1: Unexpected token

When you remove the `2>/dev/null`. Escape the '$' characters to solve this.

gofmt doesn't return an exit code 1 if there are matching files:
https://github.com/golang/go/issues/24230

To fix this, use the same trick we use in Workhorse to parse output.
Also add a `make fmt` step to format all the code properly.

Changelog: added

Previously, opentracing (if configured) was initialized late in the
gitlab-shell process's lifespan, coming just before making a gRPC
call to Gitaly.

By moving the opentracing initialization to be at process startup, we
make it available for the whole process lifecycle, which is very useful
to gitlab-sshd, as it means we'll only call tracing.Initialize() once
on process startup, rather than once per SSH connection.

To get this working, we need to introduce a context to gitlab-sshd.
This carries the client/service name, but also carries an initial
correlation ID. The main outcome of this is that all calls to the
authorized_keys endpoint from a given gitlab-sshd process will now
share a correlation ID. I don't have a strong opinion about this either
way.

Changelog: fixed