This includes an authentication method that sends a Geo signed
token from the primary using the current session's user ID, that
is then authenticated on the secondary.

Changelog: added
EE: true

Contributes to https://gitlab.com/gitlab-org/gitlab/-/issues/340366

**Problem**

Golang `mime` package skips processing unsupported encodings (see
https://sourcegraph.com/github.com/golang/go@0fd0639e4c429e147d33bfc42654fcd651f4449f/-/blob/src/mime/mediatype.go?L247).

Because of that workhorse does not incercept the upload and skip
sanitization for filename.

**Solution**

Manually detect the charset of the `filename*` and reject the upload
when charset is unsupported.

Changelog: fixed

Changelog: changed

By default, go binaries currently include only a
Go build-id, but it is also useful to include a
Gnu build-id.

Providing a Gnu build-id in a binary enables more robust
support for Gnu profiling, tracing, and debugging tools.
For example, it prevents an ugly scenario where the wrong
symbols are used when analyzing a profile that was captured
prior to a recent install of that binary.

Like all build-ids, the Gnu build-id must be unique.
Ideally it should also be deterministic, as that supports
repeatable builds, which in turn enable supply chain integrity
validation, equivalency testing, etc.

The Go build-id has both properties: unique and deterministic.
Here we generate a Gnu build-id based on the Go build-id,
inheriting those 2 properties.

We hope to make this an automatic behavior of go build in the
future, reducing overhead and risk.  But for now, this approach
approximates the required certainty of uniqueness (including
differentiating between builds that use the same source code
but different versions of go or statically linked libraries).

This reverts merge request !77688

Contributes to https://gitlab.com/gitlab-org/gitlab/-/issues/340366

**Problem**

Golang `mime` package skips processing unsupported encodings (see
https://sourcegraph.com/github.com/golang/go@0fd0639e4c429e147d33bfc42654fcd651f4449f/-/blob/src/mime/mediatype.go?L247).

Because of that workhorse does not incercept the upload and skip
sanitization for filename.

**Solution**

Manually detect the charset of the `filename*` and reject the upload
when charset is unsupported.

Changelog: fixed

The workhorse integration tests for Gitaly need to have a Gitaly process
running. It uses scripts/setup-test-env to build Gitaly, but it used a
home-grown solution to start the process.

This change switches to the "standard way" of starting Gitaly in test
for workhorse, so it has the same environment variables when set up and
started. This has an added benefit as now the Gitaly socket is tested
before the workhorse tests start.

Make test should be able to run also on a clean clone of the
repository.

Do not generate the gitaly configuration if gitaly integration tests
are not needed.

If gitaly integration tests are requested, then make should be able to
generate all the necessary binaries and configuration files without
user interaction.

Related to https://gitlab.com/gitlab-org/gitlab/-/issues/349194

This adds a custom header for Geo proxied events
through Workhorse, and uses a HLLRedisCounter on
the #show action for major controllers to store the
unique users count going through the proxy.

Changelog: added
EE: true

Changelog: added
EE: true

Part of https://gitlab.com/groups/gitlab-org/-/epics/7111

This removes the timing expectation (polling interval) from the
tests and instead introduces a middleware that ignores requests
to `/api/v4/geo/proxy`.

This reverts merge request !74979

The newUpstream method starts the goroutine that polls the Geo API,
which expects the secret to be configured, thus the ConfigureSecret
method should be called before this, instead of the NewServer method.

This reverts merge request !74329

Currently, we can't upload multiple designs at once
It fixes the bug

Changelog: fixed

The api/internal routes need to not be proxied to allow detection if
the repository exists locally for a project, and redirection to the
primary if not.

The geo/proxy_git_ssh route is used internally by gitlab-shell to
then proxy the git+ssh operations to the primary, using the internal
URL of the primary (hence why these don't get proxied and is intended
that they hit the secondary).

Changelog: changed
EE: true

Without it the progress bar is not displayed

We use a very tweaked transport to perform http calls

Let's extract it into a helper function to deduplicate code

Changelog: changed

Gitlab Rails doesn't have endpoints that require uploading
multiple files.

Let's limit it to prevent performance issues and proceed with
a proper solution out of Security Release

Changelog: security

Changelog: security

Changelog: changed

Changelog: changed

Issue: https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/1220
Changelog: added

As the secondary is read-only, we want to ensure pushes are proxied
to the primary, while reads are served localy, same with LFS files.

Changelog: changed
EE: true

zipartifacts uses a http-client based ReaderAt implementation that fetches parts of a remote zip
file by using Range headers. We don't have direct control of the ranges that will be requested, so
this test ensures that changes to the underlying zip reader won't negatively affect performance by
making more range requests than expected.

This reverts merge request !68157