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

This is to improve RAM usage when parsing references utilizing the
existing `cache` struct.

Reduces memory usage when parsing LSIF file of gitlab-workhorse
from 7MB to 4MB.

According to
https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35:

Origin servers that accept byte-range requests MAY send Accept-Ranges:
bytes, but are not required to do so. Clients MAY generate byte-range
requests without having received this header for the resource involved.

Since some servers (e.g. Dell ECS) don't send an `Accept-Ranges: bytes`
header and we are already checking that range requests are supported
when we call `HttpReadSeeker.rangeRequest`, `canSeek` only becomes a
problem and should be removed.

Since it's not clear whether https://github.com/jfbus/httprs is actively
maintained, this commit applies https://github.com/jfbus/httprs/pull/6
to our vendored module.

Closes https://gitlab.com/gitlab-org/gitlab/-/issues/223806

Vendor httprs module

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

Bump Go version in go.mod to v1.13

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

Release v8.38.0

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

Since we dropped support for v1.12 in
https://gitlab.com/gitlab-org/gitlab-workhorse/-/merge_requests/532, we
should set the go.mod version to the minimum supported version, which is
Go v1.13.

It's not clear whether this source code is maintained anymore. This is
done in preparation to apply https://github.com/jfbus/httprs/pull/6,
which is 2 years old.

Add References struct

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

Add support for AWS S3 Server Side Encryption (SSE-KMS)

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

Extract references parsing logic to a separate file and struct.
Also modified `Item` struct to have `Line` as `int32` so it'll
be fixed size.

This is in preparation for another MR wherein references will be
stored in file instead of memory.

Prior to this change, uploads to AWS S3 were only encrypted on the
server if a default encryption were specified on the bucket.

With this change, admins can now configure the encryption and the AWS
Key Management Service (KMS) key ID in GitLab Rails, and the
configuration will be used in uploads. Bucket policies to enforce
encryption can now be used since Workhorse sends the required headers
(`x-amz-server-side-encryption` and
`x-amz-server-side-encryption-aws-kms-key-id`). The bucket policy cannot
be enforced with default encryption, since that is applied after the
check.

This requires the changes in
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/38240 to work.

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

Add changelog for MR 529

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

Added configuration option PropagateCorrelationID

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

added configuration option PropagateCorrelationID and corresponding flag argument propagateCorrelationID to enable correlation.InboundHandlerOption: WithPropagation() for correlation.InjectCorrelationID

Improve test report for performance_test.go

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

Drop Go v1.12 support

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

We officially use Go v1.13+ for everything
(https://docs.gitlab.com/ee/install/requirements.html#go-versions), and
dropping Go v1.12 allows us to use new methods such as
`http.NewRequestWithContext`.

Document changelog as part of process

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

Generating a changelog entry is now required when a merge request
warrants a CHANGELOG entry.

[ci skip]

Read and parse LSIF references

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

In order to be able to "Find references" of a given range or
definition, we need to be able to read `references` items from
the LSIF file.

This will then be written to the JSON file for each range via
`references` property.

The property will look something like:

```
"references": [
  {
    "path": "main.go#L7"
  }
]
```

Each reference will be an object with `path` property. The `path`
property will point to the exact line where it is being used.

This is currently behind a feature flag (`code_navigation_references`)
which will set `ProcessLsifReferences` header to `true` when
enabled. If `false`, the `references` won't be read and generated.