Add labkit monitoring for build metrics

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

Labkit monitoring exposes a metric I wanted to add, gitlab_build_info.
This will set a gauge to the current version and build time, and as such
we can measure how fast deploys are and when the last deploy happened.

Metric exposed looks like:
`gitlab_build_info{built="20191121.084148",version="v8.15.0-5-gde6eb66"}
1`

Release v8.16.0

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

Set a time limit on git upload-pack requests

See merge request gitlab/gitlab-workhorse!24

Upgrade Gitaly client to v1.74.0

Closes #231

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

Add maven route test

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

Add NuGet route for package uploads

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

When a client does a git fetch over HTTP, workhorse performs an access
check based on the HTTP request header, then reads the entire request
body into a temporary file before handing off to Gitaly to service it.
However, the client has control over how long it takes to read the
request body. Since the Gitaly RPC only happens once the request body
is read, people can set up a connection before their access is revoked
and use it to gain access to code committed days or weeks later.

To resolve this, we place an overall limit of 10 minutes on receiving
the `upload-pack` request body. Since this is over HTTP, the client is
using the `--stateless-rpc` mode, and there is no negotiation between
client and server. The time limit is chosen fairly arbitrarily, but it
fits well with the existing 10MiB limit on request body size, implying
a transfer speed of just 17KiB/sec to be able to fill that buffer and
get a "request too large" error instead of "request too slow".

Workhorse does not expose the `upload-archive` endpoint directly to the
user; the client in that case is always gitlab-rails, so there is no
vulnerability there.

The `receive-pack` endpoint is theoretically vulnerable, but Gitaly
performs a second access check in the pre-receive hook which defeats
the attack, so no changes are needed.

The SSH endpoints are similarly vulnerable, but since those RPCs are
bidirectional, a different approach is needed.

Upgrade Gitaly client to v1.71.0

Closes #231

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

Ignore CompleteMultipartUpload ETag

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

Our ETag comparison on CompleteMultipartUpload was based on a reverse
engineered protocol.

It is not part of the S3 API specification and not every providers
compute it in the same way.

Release v8.15.0

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

Case insensitive ETag comparison

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

Some object storage providers returns upcase ETag headers.

This commit will perform the check in case insensitive mode

Upgrade gitaly to 1.68.0

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

Gitaly 1.68.0 upgrades GRPC to 1.24.0

Test against go1.13

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

Release v8.14.0

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

Keep HTTP 1.0 cache headers from sendurl proxies

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

For maximum compatiblity, the Rails application should also set Date and
Pragma, and so we should ensure that these are not overwritten by the
object storage provider.

Release v8.13.0

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

Remove test dummy Gitaly RPC handlers

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

Preserve original HTTP cache headers in sendurl

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

There are a few cases for serving uploads:

1. File storage. Rails asks Workhorse to serve the file.
2. Object storage. Rails redirects (via SendFileUpload) to the object
   storage host.
2. Object storage with `proxy_download` enabled. Rails asks Workhorse to
   proxy the download from the object storage host.

Rails also sets caching headers for uploads. In case 1, the reverse
proxy will keep those headers. In case 2, the headers are whatever the
object storage provider sets.

Case 3 is changed here. Previously, it would use the cache headers from
the object storage provider. Now, it keeps the cache headers from Rails
instead. This is better because:

1. Cache headers on the object storage provider can be hard to
   configure.
2. Even if we ask users to manually configure them, they may get it
   wrong and inadvertently allow private resources to be cached by
   proxies.
3. Even if we ask users to manually configure them and they get it
   right, they will also need to track any updates the Rails application
   makes to the cache headers it sends.

We could solve these by trying to automatically set the metadata policy
on the object storage bucket, which would also help with case 2
above. However, that has its own pitfalls. We could, for instance, say
that `uploads/-/system/user` is public with an expiry of five minutes,
and that's fairly straightforward. But then if we need to update that
policy in future to make it public with an expiry of one minute, we are
introducing coordination issues.

This would get even more complicated if we allowed caching uploads from
public projects. If the project's visibility changed, we'd need to
update the object storage metadata too. So it's a tricky problem, and
this is a relatively small code change to at least solve one case.

Changelog for 8.12.0

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

Fix health checks routes incorrectly intercepting errors

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

Simplify badgateway RoundTripper

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