Previously when the upstream application (e.g. Unicorn) timed out,
Workhorse would report an error message of the form:

```json
{
  "correlation_id": "k4mKg0snXG3",
  "error": "badgateway: failed after 61s: EOF",
  "level": "error",
  "method": "GET",
  "msg": "error",
  "time": "2019-12-02T22:05:09-08:00",
  "uri": "/admin"
}
```

Since Sentry attempts to group similar events by some fingerprint that
includes the message, the changes in timings would trick Sentry into
creating a new event. To avoid that, the new log message now looks like:

```json
{
  "correlation_id": "k4mKg0snXG3",
  "duration_ms": 60599,
  "error": "badgateway: failed to receive response: EOF",
  "level": "error",
  "method": "GET",
  "msg": "error",
  "time": "2019-12-02T22:05:09-08:00",
  "uri": "/admin"
}
```

The inclusion of `duration_ms` and the standardized `error` message makes
it easier for users to filter and parse this error.

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.

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

EXIF may contain sensitive information, when uploading
any file which may be an image (based on filename suffix),
we run it through exiftool which removes any metadata.

The port number is meaningless when the X-Forwarded-For header
is used, so let's just remove it.

Closes https://gitlab.com/gitlab-org/gitlab-workhorse/issues/201

Remove test for invalid url, as those urls won't be generated by Rails.

Don't log errors to Sentry.
Reduce helpers usage in favor of simple http error