This is a breaking API change. Instead of parsing repo path from the request
in gitlab-git-http-server, we now expect the auth backend to tell us the full
path to the repository. This change is needed to handle API download requests.

The profiler is disabled by default. It will allow us to better
understand the behavior of gitlab-git-http-server in production.

After reading the curious Git repository corruption report in
https://gitlab.com/gitlab-org/gitlab-ce/issues/2336 (where
gitlab-git-http-server was NOT being used, for the record), I feel
inclined to be a little more cautious and use SIGTERM instead of
SIGKILL to terminate the git-xxx-pack process group in case of
aborted requests.

Also discussed in
https://gitlab.com/gitlab-org/gitlab-git-http-server/issues/1 .

Splitting the program in multiple files broke the Makefile, oops.

Change in behavior: we stop panicking in the middle of writing a
response body; instead we do a 'clean' return from the handler.

This lets us drop a few global variables.

The Golang net/http HTTP server will not pass URLs with '/../' in
them to our code (see http://golang.org/pkg/net/http/#ServeMux ).

Change in behavior: we now accept requests with path '/'. This
should not be a problem; upstream GitLab (the 'auth backend') still
decides if Git access to the path is OK. We are still guarding
against traversal.

We want literal periods, not arbitraty characters. :(

TODO: add a test for this

We should not leave open a TCP connection to the auth backend
(Unicorn) in the CLOSE_WAIT state, it may take several minutes for
the HTTP response to our own client to finish.

We were seeing a resource leak:

2015/08/07 12:09:17 Get http://localhost:8080/gitlab/omnibus-gitlab.git/info/refs?service=git-upload-pack: dial tcp: lookup localhost: too many open files
2015/08/07 12:09:18 http: Accept error: accept tcp 127.0.0.1:8181: too many open files; retrying in 5ms

My guess is it was about not closing the auth response body.