Modernizing the request code

I opened an issue for modernizing the server #3328, though I think probably we could have a separate issue for refactoring the request code and timeout code.

I've mentioned in previous discussions that I'd like to experiment with disabling the in-memory cache. It adds complexity, is untested, and I think it is not buying us a lot, especially now that we have a downstream CDN. If we see the hit rate is low, and/or disabling it doesn't send performance through the floor, I think we can drop it as part of rewriting the request code.

(It may be difficult to untangle the decision about dropping the in-memory badge cache from other questions about caching. In brief, the cache that I think would be most helpful right now would be of API responses (#1545), either raw or transformed. Those could be better shared between different badges. However our most critical performance issues probably are #3027 and adding a little more capacity, and most critical ops issues are #3332 and the deployment bottleneck.)

The other thing the legacy request handler does it handle timeouts. However timeouts are much simpler, and are already built into client libraries like [got](https://github.com/sindresorhus/got).

In Discord @calebcartwright also mentioned request's EOL, and that request has good support for proxying which he uses in his self-hosting environment. We'll have to find a solution for that, too.

The issue names the request code, timeout code, and legacy request handler, but no files or tests. Start by locating those entry points and comparing the current handler with the got client library; resolve the caching and proxying decisions before defining a done condition. Done should include an explicit timeout and proxy approach and a decision about the in-memory badge cache.

Written by the indexing model from the issue text.