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.