RAM usage of parsing LSIF references are now back to normalcy and
feature works.

This removes the code in workhorse for determining whether parsing
references is enabled or not. It'll now always be enabled.

Make more use of testify/require

See merge request gitlab-org/gitlab-workhorse!573

Use switch statement instead of long if-else

See merge request gitlab-org/gitlab-workhorse!572

Stop using require.New and assert.New

See merge request gitlab-org/gitlab-workhorse!567

Use more require in internal/{upload,upstream}

See merge request gitlab-org/gitlab-workhorse!571

Tests: consistent helper function names

See merge request gitlab-org/gitlab-workhorse!566

Readme formatting cleanup

See merge request gitlab-org/gitlab-workhorse!548

Fix nil pointer exception when no object storage config is defined

See merge request gitlab-org/gitlab-workhorse!565

This is a regression that was caused if the `[object_storage]` config
section were omitted.

[ci skip]

Resize images on-demand with `gm convert`

See merge request gitlab-org/gitlab-workhorse!546

via graphicsmagick

[ci skip]

Add Azure Blob Storage support

See merge request gitlab-org/gitlab-workhorse!555

This merge request introduces a client for Azure Blob Storage in
Workhorse. Currently customers wanting to use Azure Blob Storage have to
set up a Minio Gateway
(https://docs.gitlab.com/charts/advanced/external-object-storage/azure-minio-gateway.html),
which isn't ideal because it requires customers to maintain their own
proxy server for Azure. We have a number of customers who want native
support for Azure Blob Storage.

Unlike AWS and Google, Azure needs to use an Azure client inside
Workhorse to support direct uploads. Using standard HTTP transfers with
pre-signed URLs with the Azure Put Blob API
(https://docs.microsoft.com/en-us/rest/api/storageservices/put-blob)
doesn't work because Azure doesn't support chunked transfer encoding.
However, Azure does support uploading files in segments via the Put
Block and Put Block List API
(https://docs.microsoft.com/en-us/rest/api/storageservices/put-block),
but this requires an Azure client that can speak this API.

Instead of embedding the Microsoft Azure client directly, we use the Go
Cloud Development Kit (https://godoc.org/gocloud.dev/blob) to make it
easier to add other object storage providers later. For example, GitLab
Rails might return this JSON payload in the
`/internal/uploads/authorize` call:

```json
{
   "UseWorkhorseClient":true,
   "ObjectStorage":{
      "Provider":"AzureRM",
      "GoCloudConfig":{
         "URL":"azblob://test-bucket"
      }
   }
}
```

The `azblob` scheme is managed by the Go Cloud `URLMux`
(https://godoc.org/gocloud.dev/blob#URLMux).

Converting our existing S3 client with Go Cloud should be done later
(https://gitlab.com/gitlab-org/gitlab-workhorse/-/issues/275).

This changes requires
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/38882 to work.

Omnibus configuration changes are in
https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4505.

Part of https://gitlab.com/gitlab-org/gitlab/-/issues/25877

[ci skip]

Add project level route for conan package uploads

See merge request gitlab-org/gitlab-workhorse!558

Security release process

See merge request gitlab-org/gitlab-workhorse!507

Reduce code duplication in LFS upload preparer

See merge request gitlab-org/gitlab-workhorse!560

We reuse the standard object storage upload preparer to avoid
duplication of code and add a test. This is done in prepration for
adding new fields to the filestore options.

Update staticcheck and ignore Protobuf v1 deprecation warnings

See merge request gitlab-org/gitlab-workhorse!559

This update is done in preparation for importing the Go Cloud SDK.  To
fix this properly, we will have to update Gitaly to use Protobuf v2:
https://blog.golang.org/protobuf-apiv2

See https://gitlab.com/gitlab-org/gitlab-workhorse/-/issues/274.

Refactor uploaders to use different upload strategies

See merge request gitlab-org/gitlab-workhorse!553

Fix unnecessary fmt.Sprintf (S1039)

See merge request gitlab-org/gitlab-workhorse!556

This was flagged in
https://gitlab.com/gitlab-org/gitlab-workhorse/-/jobs/684053889.

Previously it was particularly tricky to add a new object storage method
because you had to be aware of how to deal with different Goroutines and
contexts to handle the Workhorse upload flow
(https://docs.gitlab.com/ee/development/uploads.html#direct-upload). In
addition, the execution engine to handle this was duplicated across
multiple files. The execution engine essentially did the following:

1. Set up an upload context with a deadline
2. Record upload metrics
3. Initialize cleanup functions
4. Initiate upload
5. Validate upload ETag
6. Do cleanup (e.g. delete the temporary file)

To reduce code duplication and to make it easier to add new object
stores, the common execution sequence is now encapsulated in the
`uploader` `Execute()` method. We also introduce an `UploadStrategy`
interface that handles the details of the uploads, and `Execute()` calls
methods on this interface.

Now adding a new object storage type is a matter of implementing the
`UploadStrategy` interface without needing to understand the details of
the execution engine.

[ci skip]

Cache references in file

See merge request gitlab-org/gitlab-workhorse!544

Fix HTTP Range Requests not working on some S3 providers

Closes gitlab#223806

See merge request gitlab-org/gitlab-workhorse!549