Don't `git push` on the HTTP thread

[alexcrichton]

Currently the architecture of this server is to have a pool of worker threads and each request is assigned its own thread. Threads are only re-used after a request completes. This is OK most of the time, but there's a lot of blocking things that we do on each thread:

• Talk to the database via rust-postgres
• Talk to S3 via curl
• Talk to GitHub via libgit2

Right now I believe postgres/S3 to be robust enough to not be hugely worrisome, but sometimes threads pushing to github can block for very long periods of time (for one reason or another). An example of this is when GitHub went down recently due to a DDoS, causing all of our pushes of new crates being published to take a very long time. What ends up happening is that all worker threads are exhausted by waiting for a git push to finish, preventing new requests from being served. At the very least it would be nice to time out the push operation, but it does not appear that libgit2 supports this kind of timeout right now, so that may not be an option.

To get around this, there are a few possible strategies:

• Don't actually run git push on the HTTP thread, instead do it on a worker thread elsewhere. This would involve building up a queue of git push requests which is processed occasionally, but it also loses the guarantee that when /api/v1/crates/new returns that your crate is 100% published (it may still take some time to make its way into the index).
• Add timeouts to the libcurl transport for libgit2 (located in git2-curl) and use that instead. Note that this could still end up blocking the pool.
• Route all publish requests to a separate thread pool so blocked pushes don't cause interference with other threads.

[brson]

Removed P-high. No activity. Seems to work fine.