feat(store): use RocksDB-backed persistent account state forest

[kkovaacs]

As described in #1978 we're currently not using a persistent backend for the the AccountStateForest and rebuilding can take a long time (up to 9 minutes on our last testnet).

This PR implements the RocksDB-based persistent storage backend for the account state forest while keeping the existing logic for reconstructing its state from SQLite.

Upon startup the account state forest is checked. If it's empty we start reconstructing the state from SQLite. For a non-empty account state forest we check if vault and storage map commitments in the forest match data in SQLite for all public accounts.

For reference: I've used the stress test tool to generate a database with 50k public accounts, each with 2 vault assets and 64 storage map entries (in a single slot). Initializing the in-memory account state forest takes about 5 minutes, while initializing the RocksDB backed forest about 10 minutes. Loading and verifying persistent state (once persistent storage has been initialized) takes about 1.3s.

[kkovaacs]

Note: this PR is incorrect in the sense that account state forest get/set operations are now potentially blocking, so those should be performed on a blocking task. We already have this issue with the account and nullifier SMTs, and I'd prefer to solve that in a follow-up PR.

[Mirko-von-Leipzig]

I think this looks good. Will maybe do another pass later.