GitLab

Two cases in particular, lacking a `Content-Type`,  gave us trouble:

* Transfer-Encoding: chunked
* No content-type and no transfer-encoding

Both of these are permitted by the HTTP RFC (cases 3 and 7), and we
can talk to arbitrary HTTP servers via sendurl, so it's imperative that
we handle them correctly. This commit adds tests for both cases.

Responses of the latter type are transparently converted to responses
of the former type. This is an automatic behaviour of the Go stdlib,
which doesn't really support making the second type of response
directly. Since Transfer-Encoding is a hop-by-hop header, this type of
encoding is extremely common, and we're still streaming, instead of
accumulating, the data, I think this is acceptable.

Git and Gitaly stream upload-pack response data as soon as it is
available. Some HTTP clients do not support the response being streamed
back while the server is still reading from the request body. To avoid
this, the request was buffered in to a temporary file before passing it
to Gitaly for handling. The buffer had a maximum size of 10MB, which is
now reached by requests to large repositories. These requests were then
truncated, causing Git to fail.

This commit fixes the problem by removing the request buffering and the
maximum size. Instead, the response is buffered in to a temporary file
until the request body is fully read, thus avoiding the problem of
streaming the request and the response simultaneously.

This fixes performance bar not working with AJAX requests.

Both LabKit and Rails were injecting duplicate X-Request-Id headers into
the response stream, which caused the frontend to be interpret the value
as a comma-separated value (e.g. LdEgVXsp1R4, LdEgVXsp1R4).

The new flow behaves as the following:

1. Workhorse injects X-Request-Id to the inbound HTTP request to Rails
2. Rails looks up this value in its RequestId middleware. Since the
value exists, Rails sets the X-Request-Id response header to this value.
3. Workhorse doesn't append another header in the response.

Distributed tracing should still work fine because Workhorse still
generates the correlation ID.

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/60111

This is a necessary change to solve a security issue. For more details,
see this issue: https://gitlab.com/gitlab-org/gitlab-workhorse/issues/197

This is a version than includes the new gitaly-proto, which has the
package name changed. Now gitalypb is used everywhere. The client of
Gitaly is updated too, as only one proto definition can register a type.

Closes gitlab-org/gitaly#125

We are in the middle of making the Gitaly 'Repository' message contain
more fields than it used to. This change makes sure that workhorse
automatically passes through the new message format (as long as the
gitaly client versions in gitlab-rails and workhorse match).

No changes besides the import path