change(state): Expose ZebraDb methods that can create different kinds of databases

[teor2345]

Motivation

We want to be able to create a blockchain scanner results database as a completely separate database directory and instance. This is a rough draft of a first step, which allows different kinds of databases to be created using ZebraDb::new().

Close #8001

PR Author Checklist

Check before marking the PR as ready for review:

• Will the PR name make sense to users?
• Does the PR have a priority label?
• Have you added or updated tests?
• Is the documentation up to date?

If a checkbox isn't relevant to the PR, mark it as done.

Specifications

See the ticket for a rough design.

Complex Code or Requirements

There are a lot of code changes in this PR already, so I'd like to do the scanner database and its tests in another ticket.

Solution

• Provide access to ZebraDb and WriteBatch outside the state
• Pass column families to ZebradDb::new()
• Allow the database kind and current version to be changed in:
  • config.rs
  • finalized_state.rs
  • ZebraDb
  • DiskDb
  • upgrade.rs
• Make some upgrade.rs methods easier to use, simplify their arguments

Testing

Tests for new kinds of databases will be added when we add this database to the scanner.

The current state tests were updated and give good coverage.

Review

This PR blocks "Persistent storage of scanner results" in the MVP in #7728.

I'm looking for a review for a correct refactor. Missing functionality or additional refactors should go in the follow-up tickets #7926 and #7937.

Reviewer Checklist

Check before approving the PR:

• Does the PR scope match the ticket?
• Are there enough tests to make sure it works? Do the tests cover the PR motivation?
• Are all the PR blockers dealt with?
  PR blockers can be dealt with in new tickets or PRs.

And check the PR Author checklist is complete.

Follow Up Work

• feat(zebra-db): Split low level database code inside zebra-state #7926:

  • Split the state upgrade code so it doesn't try to run on the scanner format
  • Move all generic database methods to DiskDb, and use it to create the scanner database, so other databases don't have access to state-specific methods
  • move the old versions cleanup task into DiskDb

• Create a zebra-db crate #7937

[oxarbitrage]

Apart from some unused code warnings this looks good, @teor2345 and I were in a meeting earlier today where they explained me the important parts of this PR, changes put ourselves one step closer to our needs of creating a database from the zebra-scan crate.