analyzer/fast-sync: Reduce DB contention by writing updates into a writeahead log

[mitjat]

The task

There is a handful of UPDATE queries that are limiting the speed of fast-sync indexing:

• Queries that update last_mutate_round in evm_tokens, evm_token_balances
• The query that updates the epoch range (`UPDATE chain.epochs ...`)

For the first, we see many reports of deadlocks. For the latter, GCP's query insights lists it as a query with outsized "lock wait time", meaning it doesn't quite produce a deadlock, but it's waiting for the row to become available for writing, which slows the whole tx down (and likely increases deadlocks elsewhere).

For all of these, the approach is the same: Create a dedicated fast-sync temp table; then replace operations that are currently UPDATEs with an INSERT into the temp table; then in FinalizeFastSync(), aggregate the temp table into UPDATEs in the primary tables.

This PR

Running the fast-sync analyzer with almost any parallelism (as low as parallelism=5) caused significant DB lock contention and consequently slowdowns.
This PR mostly removes the contention by replacing table UPDATEs with INSERTs into new temporary tables in a new updates_todo schema. Then after fast-sync, those temp tables get merged back into the "real" tables.

Testing: I locally modified the e2e_regression config to use fast-sync for the majority of the scanned range. Confirmed there were no diffs to the expected output.

[mitjat]

Unrelated obsolete code

[Andrew7234]

Looks good overall, thanks!