Don't lock more than 1 row at a time in update-downloads

[sgrif]

Prior to this commit, bin/update-downloads will hold a lock on every
row it updates for the entire batch of 1000. Each row gets locked when
it is updated, but the lock isn't released until the whole transaction
is comitted. This means that the first row in the batch is locked for
the whole transaction, but the last row in the batch isn't locked longer
than it should be.

Processing 1000 rows is routinely taking more than 30 seconds to
complete. Whenever it does, this causes requests to time out. Even when
it doesn't, this locking behavior is the reason that our 99th percentile
response time is getting to be so bad.

The endpoint affected by this is /crates/{name}/{version}/download. In
other words, this bug is causing cargo install to fail. Even when it
doesn't, this bug is causing it to take seconds when it should take
milliseconds.

By establishing a transaction per row instead of per batch, we retain
atomicity, without holding a lock for the whole batch. To keep
everything atomic, we need to update the global counter per row instead
of per batch.

This relies on the invariant that no rows in version_downloads get
touched once date != CURRENT_DATE other than by this script.

I believe this is also the root cause of #1304, and that we can maybe
revert #1312

[sgrif]

bors: r+

[sgrif]

bors: r-

(clippy lint failed, CI passed otherwise, just going to manually merge after fixing)

[bors-voyager]

Canceled