Eliminate the async dependency in consensus-types.

Stub out the status field in ProofWithData with the vector that's
evenutally supposed to be retrieved, until we figure out if we need
the field and the whole structure at all.

aptos-consensus had code that provided consensus-types data
in asynchronous sends. Since we are not likely to need this crate
anyway, cut it out of the workspace. Also remove any dependent crates.

It's only used in test code, move it to dev-dependencies

ENG-251 aptos-logger: cut out async logging

ENG-180: Cut out async dependencies from consensus-types and async-vm

…-block-reversion

ENG-206 Implement Block Reversion

Some tests still had these.

AptosDB::commit_reversion_ledger_info
does the same thing as commit_ledger_info,
just use that method instead.

This wrapper is meant to represent the finalized state
for the API.

No randomness allows us to verify the hash.

get_read_delegatee needs to deref to get the vtable
for the pointee type.

FinalityView::set_finalized_block_height better describes
the argument.

This reverts commit 7f3e0e5.

Use ? for terser, idiomatic code that can be cribbed for production.

Draft a test for FinalityView, checking that the latest_state_checkpoint_view
extension method gets us the view into finalized state.
StateView support in the mock is needed to complete the test.

In FinalityView::set_finalized_block_height, remove the outdated
sanity check, add comments explaining why we can use the empty hash
and no signatures specifically for Movement.

For set_finalized_block_height, retrieve ledger info from the
corresponding epoch or use the latest.

Exercise the DbStateView instance returned from
latest_state_checkpoint_view. No testing yet if the state
matches expectations for the finalized version.

This reverts commit 1731cce.

Access to account state is convenient to test with.

`FinalityView`, a `DbReader` wrapper to represent a finalized state

…mentation

Faucet Instrumentation

Pass LedgerInfoWithSignatures by reference like in other methods.
Do not try to set epoch and version on the LedgerInfo in a way that
does not work. Instead, it's expected to be correct for the latest
pre-revert version.

All necessary information can be obtained from
either the LedgerInfoWithSignatures, or the current
database state.

Update both progress values in the ledger metadata
schema in one batch.

…vert

Make `LedgerInfo` the source of truth on revert

Rewrite the computation for rewards rate to avoid
division by zero when the epoch duration exceeds one year.

…n-long-epochs

fix: prevent zero divide on long epoch duration

Use batches correctly: one per schema, commit all batches.

Commit (and validate) the LedgerInfoWithSignatures
and update the DbMetadataKey::OverallCommitProgress value
first thing when reverting commits.

Remove block information from ledger metadata db,
update the LedgerCommitProgress marker in the same atomic batch.
In StateKvDb, reuse the commit method to update version markers.

Stub out reversal of store indices from StateStore, add TODO comments
on what will need to be cleaned up.

Consistently reuse the prune functionality available for
the relevant tables to remove the ranges of versions. Remove
methods added earlier that
Fix off-by-one errors with version ranges to prune.

These were added to make LedgerInfo and BlockInfo work
when reverting, but are no longer needed after rewrites.

Add a ResetLock to expose scoped locking used in `reset`,
to implement atomic updates of buffered state in revert_commit.

…tream-helper

A Helper for Syncing w/ the Upstream

Replace todo! in struct value initializers with sensible values.
Apply some typo fixes.