feat(sync/pending): take complete_previous_block off the critical path

[CHr15F0x]

This PR is based on the 1st pending data optimization PR, and is a preparation for a follow-up PR which will address the issue of chaining within a gap larger than 2 blocks from the latest preconfirmed to the latest block locally committed to storage, which is the major culprit in preconfirmed latency as we experience it today.

The PR takes advantage of the fact that complete_previous_block can be taken off the critical path and hence the cache can be updated faster with the latest preconfirmed, while any remaining tail transactions to the previous block will still be served for the subscriptions, without re-invalidating the latest RPC read view.

For this reason two consumers of the cache were introduced:

• the read view, which must never regress and provides the latest state,
• the subscriber view, which provides out-of order tail transactions of the previous block in case complete_previous_block yielded any.

Other changes in the PR:

1. The next_block_number != committed_head + 1 in store_pre_confirmed is relaxed, because it relies on the current watch which can briefly lag behind the DB. When it lags by one, a perfectly good pre-confirmed view fails the exact check and is dropped. Exact chaining remains the RPC read path's responsibility. Earlier, this was somewhat redundant on the sync and RPC side of things.

2. try_from_pre_confirmed_block and try_from_pre_confirmed_and_pre_latest are now called from within block_in_place to make sure that other task are making progress in a multithreaded runtime (these calls are otherwise inlined in tests).

[CHr15F0x]

This optimization is not worth the cost, which is introducing race condition in subscriptions for the sake of gaining 1RT of preconfirmed latency (given it chains properly).