Move history tree and value balance to typed column families

[teor2345]

Motivation

This is another part of ticket #7833, making sure that the new typed column families work for more complex situations in the state. These commits or PRs will become examples in the documentation.

This PR converts the history tree and value balance to typed column families, and cleans up some risky and redundant code.

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.

Database Format Docs

Please check the types in the PR match the existing types in the database:
https://github.com/ZcashFoundation/zebra/blob/main/book/src/dev/state-db-upgrades.md#current-state-database-format

Complex Code or Requirements

This PR removes complexity by using consistent types for reading and writing column families.

Solution

• Convert history trees to typed column families
  • Create methods for legacy (compatibility with 1.2.0 and earlier) and raw types (upgrade from 1.2.0 to 1.3.0)
  • Delete redundant format code that makes risky assumptions about history tree formats on disk
• Convert value balance to typed column families
• Add typed methods for writing into existing batches (owned and borrowed)
• Make it easier to pass references when writing typed column families (by taking &Key and &Value and relying on auto-deref)
• Always pass ZebraDb to database methods

Related changes:

• Clean up and document zebra-state exports

Unrelated cleanups:

• Remove a 1.72 lint exception now 1.74 is stable

Testing

Review

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

[upbqdn]

The solution in this PR contains this item:

• Always pass ZebraDb to database methods

I reverted this change because it caused a very tricky bug where Zebra would compile with cargo build, but not, for example, with cargo build --package zebrad or in other cases. We'll need a bigger refactor if we want to do that change.

I also manually resolved merge conflicts and fixed some API bugs that the merge introduced.

Otherwise, this PR looks good.

[upbqdn]

The cause of the bug was that passing ZebraDb to functions that expect DiskDb created a reliance on a Deref impl for ZebraDb targeting DiskDb, which is conditionally compiled if the proptest-impl or shielded-scan features are enabled during the compilation of zebra-state. By a weird coincidence, running cargo build or cargo build --release seems to enable shielded-scan when compiling zebra-state, so the Deref impl gets compiled in that case. It looks like this is a bug on its own because shielded-scan should not be enabled. Running, for example, cargo build --package zebrad doesn't enable the feature, so the Deref was missing, and Zebra didn't compile.

[teor2345]

The cause of the bug was that passing ZebraDb to functions that expect DiskDb created a reliance on a Deref impl for ZebraDb targeting DiskDb, which is conditionally compiled if the proptest-impl or shielded-scan features are enabled during the compilation of zebra-state. By a weird coincidence, running cargo build or cargo build --release seems to enable shielded-scan when compiling zebra-state, so the Deref impl gets compiled in that case. It looks like this is a bug on its own because shielded-scan should not be enabled. Running, for example, cargo build --package zebrad doesn't enable the feature, so the Deref was missing, and Zebra didn't compile.

We could have enabled the Deref impl in all builds, or called the db() method where needed.

But we'll deal with this when we split ZebraDb and DiskDb properly in #7937.