Gitaly deprecated and removed Namespace Service, we can remove
a repository instead

The allowed commands must be scoped to namespaces:

- git push/pull/archive
- git lfs authenticate

GitLab Shell detects that the passed key is a certificate and
requests /authorized_certs instead of /authorized_keys endpoint

This explicitly imports gitaly v16 instead of v15 and removes the
old one from `go.mod`.

Prior to this change personal access tokens without a ttl would never
expire. In Gitlab 15.4 we deprecated non-expiring tokens and are
scheduled for removal in 16.0.

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

This change alters the gitlab-shell command for creating tokens to
ensure add a default limit of 30 days.

Closes https://gitlab.com/gitlab-org/gitlab-shell/-/issues/640

It imitates a push to the secondary and verifies that the push
is redirected to the primary

This commit also excludes gitlab-shell from dependencies:

Gitaly specifies Gitlab Shell as a dependency as well in order
to use gitlabnet client to perform API endpoints to Gitlab Rails.
As a result, Gitlab Shell requires Gitaly -> Gitaly requires an
older version of Gitlab Shell -> that version requires an older
version of Gitlab Shell, etc. Let's use exclude to break the
chain earlier

After https://gitlab.com/gitlab-org/gitaly/-/merge_requests/4766
has been introduced, the test started fail because we basically
cancel the git-receive-pack after the output is received

This commit gracefully closes the connection to make the test
pass

While gitlab-shell currently has a major version of v14, the module path
it exposes is not using that major version like it is required by the Go
standard. This makes it impossible for dependents to import gitlab-shell
as a dependency without using a commit as version.

Fix this by changing the module path of gitlab-shell to instead be
`gitlab.com/gitlab-org/gitlab-shell/v14` and adjust all imports
accordingly.

Changelog: fixed

- If an integer is specified, we assume that these are seconds
- A duration of format "500ms", "10s", "1m", etc... accepted

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

When gitlab-sshd has been introduced we've started running our
own SSH server. In this case we're able to cache and reuse
Gitaly connections and Registry.

It helps to reduce memory usage.

Until recently, Gitaly was silently swallowing any errors returned by
SSH `git upload-pack` processes. Clients would still receive stderr
output and a non-zero return code, but Gitlab-Shell would receive error
as nil and log success.

With 9deaf47f1ecb00f0f36d18ee4a0fb1576f5a0efe Gitaly will now return an
error when git fails, but this causes Gitlab-Shell to print out the
GRPC error code as a message to the client:

> fatal: couldn't find remote ref not-a-real-ref
> fatal: the remote end hung up unexpectedly
> remote:
> remote:
> ========================================================================
> remote:
> remote: rpc error: code = Internal desc = SSHUploadPack: exit status 128
> remote:
> remote:
> ========================================================================
> remote:

The `remote:` text gives no additional context for the user and adds
clutter.

This commit suppresses the additional message added by Gitlab-Shell on
failure when the error type is `Internal`, returning client output to
the format it was prior to the Gitaly change.

Before 9deaf47f1ecb00f0f36d18ee4a0fb1576f5a0efe, Gitaly would return
success for `SSHUploadPack` and `SSHUploadArchive` regardless of the
exit code of the `git upload-pack|archive` process. As a result, the
gitlab-sshd acceptance tests could rely on no errors being returned from
Gitaly.

Currently these tests send the minimum request needed to start a
session, causing the server git process to fail as the `0000` flush
packet to end the session is never sent.

This commit fixes the tests by sending the full request/response needed
for a successful git operation.

Due to the way sshd works, gitlab-shell could be called with a single
string in the form:

```
/path/to/gitlab-shell -c key-id
```

However, due to the tightening of the regular expressions in fcff692b
this string no longer matches, so logins would fail with:

```
Failed to get username: who='' is invalid
```

This can be reproduced by changing the user's shell to point to
gitlab-shell. For example:

```
usermod git -s /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell
```

While setting gitlab-shell as the user's shell isn't officially
supported, gitlab-shell still should be able to cope with the key being
specified as the last argument. We now split the argument list and use
the last value.

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

Use reflection to log the command we are about to execute, both in
gitlab-shell and gitlab-sshd. Include the environment, which has all
the context we need to understand what the command is expected to do.

Changelog: added

It adds correlation ids wherever possible