Allow ScoreUploader to process replays concurrently

[bdach]

As things stand, ScoreUploader is inherently single threaded. Today, @peppy noticed that replay uploads have started piling up:

and @ThePooN pointed out that this wasn't exactly new, and started happening a few days before already as bursts of pending uploads that then go back down eventually, which also has the effect of increasing the memory footprint of the spectator server instance:

With no apparent direct cause (as in, no apparent deploy or change that broke it), the working theory is that something may be throttling the upload process (apparently it was doing ~1 score per second which seems way too slow) and maybe throwing more threads at it may help. So this diff attempts to do that, using channels (think BlockingCollection but async).

I admittedly don't have much experience working with Channel<T> so I'm not super sure how well this is gonna behave. One notable thing to read in the docs of that class is this:

Whenever a Channel<TWrite,TRead>.Writer produces faster than a Channel<TWrite,TRead>.Reader can consume, the channel's writer experiences back pressure.

I'm not sure I understand the full implications of whatever that means; I know what backpressure means, but depending on how it's done, it might be decent, or it might be not. This probably needs more testing in general but I'm not super sure how to test this sort of thing because this is the sort of thing you only can observe working properly under load, but I wrote it and it might be useful so I'm PRing it to see if there's at least interest to pursue this further and maybe do some stress testing on.

The degree of concurrency is controlled via an envvar (REPLAY_UPLOAD_THREADS). Yes, this means that changing the degree means restarting the instance. That was considered acceptable in discussion.

(As an aside I considered merging REPLAY_UPLOAD_THREADS with SAVE_REPLAYS to have REPLAY_UPLOAD_THREADS=0 mean "replays off" but it's annoying because tests depend on SAVE_REPLAYS being toggleable in runtime, which just works if it's done as it was in Enqueue() but is quite annoying to do if you need to kill/spin up threads on demand on the reader end just for tests, and I wasn't super sure that was a reasonable thing to do to begin with, so I didn't in the end. Can reconsider if that would be considered nicer.)

[peppy]

Looks solid enough. Using channels has been on my bucket list and it's good to see they are pretty low overhead.