[Fix] Pause BFT block advancement during sync

[kaimast]

This PR aims to fix #3911 and #3636.

Recently, we added CheckBlockError as a machine-readable response to failures in block checks. The proposed changes use this new error type to differentiate between invalid blocks, and cases where the ledger has already advanced, and the proposed block is contained in the ledger already.
The snarkVM changes also ensure that calls to the ledger are atomic, but provides no transactional guarantees across multiple invocations of Ledger functions.

BFT has a lock field that aims to protect, block advancement. This lock already existed before this change, but was not accessible from outside the struct. A problem with this setup is that check_block_content and advance_to_next_block are dependent operations. Generally, one assumes that if the former succeeds, the latter will also. However, without additional locking, BFT can call advance_to_block between Sync's calls of check_block_content and advance_to_next_block. In this case, Sync second call will fail.

The implementation implements an approached based on optimistic concurrency control to address this. Sync builds a chain of PendingBlocks without grabbing the BFT lock (otherwise, Sync would hold the lock for long periods of time).
Once a chain of pending blocks has reached the availability threshold, it will grab the lock, check their contents for correctness, and advance the ledger. In this step, check_block_content will verify the height of the block again and, if the height is below the current ledger height, Sync will abort and retry.

The main change for BFT is that update_dag does not grab the lock anymore, but callers are required to grab the lock before calling update_dag. There is a new method BFT::pause_for_block_sync that Sync calls before trying to commit blocks.
I removed the ALLOW_LEDGER_ACCESS parameter from update_dag to remove complexity from this function. This flag was only set to false for some tests, and does not seem to be needed any more even in this case, as the LedgerService abstraction allows to simply ignore writes. I would like to eventually have separate update_dag functions for sync and BFT, but this PR already reduces the complexity of the function noticeably.