SA: Improve concurrency robustness of CRL leasing transactions

[aarongable]

In a few places within the SA, we use explicit transactions to wrap read-then-update style operations. Because we set the transaction isolation level on a per-session basis, these transactions do not in fact change their isolation level, and therefore generally remain at the default isolation level of REPEATABLE READ.

Unfortunately, we cannot resolve this simply by converting the SELECT statements into SELECT...FOR UPDATE statements: although this would fix the issue by making those queries into locking statements, it also triggers what appears to be an InnoDB bug when many transactions all attempt to select-then-insert into a table with both a primary key and a separate unique key, as the crlShards table has. This causes the integration tests in GitHub Actions, which run with an empty database and therefore use the needToInsert codepath instead of the update codepath, to consistently flake.

Instead, resolve the issue by having the UPDATE statements specify that the value of the leasedUntil column is still the same as was read by the initial SELECT. Although two crl-updaters may still attempt these transactions concurrently, the UPDATE statements will still be fully sequenced, and the latter one will fail.

Part of #8031

[beautifulentropy]

This looks like a good fix. It might be worthwhile to add a test that explicitly checks for concurrent shard leasing collisions, but I won't hold approval for it.