Design and prototype moving some transaction queue functionality and related overlay features (such as flooding and flow control) to the background. Depends on #4127, as snapshots are needed to properly validate transactions.

• background overlay: move expensive overlay functionality not related to business logic to the background #4320
• background overlay: move doing transaction validation in the background before forwarding to tx queue, fast failing invalid transactions #4316
• background ledger close: rewrite externalize path to continue buffering ledgers during ledger close #4317
• LedgerTxn is not thread-safe: switch read-only paths to BucketList snapshots #4315
• Thread-safe publish path. Implementing consider moving as much of the checkpoint building logic inline with closing ledgers #4212 will simplify things by removing one of the SQL concurrent users, but we still need to deal with SCP and peer management persisting state on the main thread.
• background ledger close: implement concurrent database access #4319
  • Switching to BucketListDB exclusively would make it easier to organize work on main vs background threads to ensure one thread isn't blocked waiting for the other (e.g. externalize waiting to persist data while ledger close is applying an expensive ledger will block main thread; with BucketListDB). We still need to figure out what to do with offers though.
  • Investigate startup time delay for one time DB migration
• background ledger close: overhaul of core interfaces (tech debt) #4318
• background ledger close: immutability. Some areas of core are not immutable, and therefore not thread-safe. Prime example is TransactionFrame which stores and modifies state from different modules in core (tx queue, apply time). There's already some prior work on this front, see Remove mutable result from TransactionFrame into test-only classes #3391 (and a corresponding issue Refactor TransactionFrame to be immutable #2163)
• Taking advantage of the improvements. With all of the above changes implemented, we might not see the impact expected due to the existing conservative limits in core. Tune core limits to take advantage of freed main thread capacity #4435 tracks tuning of core to actually take advantage of freed capacity on main thread.