Archival state support for state_db and native_db

[dubbelosix]

Description

Basic support at the code level to read archival state for

1. state_db (jmt)
2. native_db (accessory)

Changes

1. Added archival_version to ProverStorage
2. Support for NativeDB and StateDB for versioning
3. Test cases for querying archival state using ProverStorage and WorkingSet for accessory and jmt

Pending

Expose archival state via RPC macros

[codecov]

Codecov Report

Merging #1170 (ab46a03) into nightly (d624e21) will increase coverage by 0.1%.
Report is 3 commits behind head on nightly.
The diff coverage is 96.5%.

❗ Current head ab46a03 differs from pull request most recent head 9df60cd. Consider uploading reports for the commit 9df60cd to get more accurate results

Additional details and impacted files

Files	Coverage Δ
full-node/db/sov-db/src/schema/tables.rs	88.3% <100.0%> (+3.3%)	⬆️
...system/module-implementations/sov-evm/src/hooks.rs	96.1% <100.0%> (ø)
module-system/sov-modules-core/src/storage/mod.rs	92.6% <ø> (ø)
module-system/sov-state/src/prover_storage.rs	93.6% <93.7%> (-0.2%)	⬇️
full-node/db/sov-db/src/native_db.rs	97.7% <95.0%> (-2.3%)	⬇️

... and 3 files with indirect coverage changes

[citizen-stig]

With this change, we use iterator on every access to the database.

Do we want to measure performance impact on regular execution?

Maybe it is too late to discuss it, but it looks like archival state taxes on regular execution.

I am raising this point, because together with ForkManagement our storage can become bottleneck.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
0 out of 2 committers have signed the CLA.

❌ dubbelosix
❌ cemozerr
_{You have signed the CLA already but the status is still pending? Let us recheck it.}