Audit and harden concurrent access to SCP history tables used during consensus and publishing

[marta-lokhova]

Currently in master scphistory and scpquorums are accessed concurrently:

• SCP history is written during consensus on the main thread (append-only)
• During publish, SCP history is queried from the background thread (select rows)
• During maintenance, SCP history is deleted (delete rows)

This seems to work as we haven't run into a single serialization issue for years (probably because we don't touch the same rows), but it's definitely a footgun. If we change any of these queries, we may run into concurrent DB access errors (and triggering those might be quite difficult, so hard to say when it'd get discovered)

We should:

• Confirm this actually works
• Write documentation on these queries
• Consider just doing checkpoint building on the main thread. Tx history maintenance burden has been significantly reduced as of v22.1.0, so it seems plausible we could construct the checkpoint on the main thread without much overhead.