Testing and merging #7270 to make persistence work.

[ghost-not-in-the-shell]

The diffs for persistent_frontier is not processed immediately (they are processed in a batch style) which causes the state of persistent database may be out of sync with snarked ledger in transition frontier.

In order to solve this we need to add a queue of snarked ledger backups to match the state of persistent_frontier.

As I re-examine #7270, I found that I broke the invariant of Singleton Factory there. I need to restructure the PR to fix it.

This change would make persistence frontier much more usable than it is now. And it's a medium size change that need to test on a qa-net. I give it a size Large because the testing would take some time.

[aneesharaines]

@ghost-not-in-the-shell to add details on how this can be tested

[ghost-not-in-the-shell]

For testing, ideally I can just run a node locally and connect it to an existing network at epoch 2 or greater and test the persistent frontier behavior locally. This could be possible because #7270 should not change the behavior of bootstrap or catchup or any RPC interfaces. And the functionality of persistent frontier can be tested on a local machine.

If this is not viable, then we want to start a small network with 5 nodes and small k (so that epoch should be shorter), in this case we need to run the network to pass at least 2 epochs and then we can start testing the persistent frontier on this network.

7270 is meant to solve the mismatch between persistent_frontier and snarked_ledger, there's some edge cases could be hard/rare to capture so we might want to add some top-level instruction to intervene with the persistent_frontier sync in order to manually trigger those edge cases.