feat: add tests for sparse and merkleized blueprint proof generation

[netrome]

Closes #2907

This PR does two things:

1. The bulk of this PR is a pure refactor of the basic_merkleized_storage_tests and the root_storage_tests macros. Instead of having the tests defined within the macros, the tests themselves are broken out to a separate helper trait (one for each module). This provides better type safety and makes it easier to maintain and develop the tests.
2. Secondly, this PR adds tests for proof generation and verification for the merkleized and SMT blueprints. See the test_can_generate_and_validate_proofs tests in the merklized.rs and sparse.rs blueprint impls. These tests provide examples of how proof generation and validation works for the respective merkle tree implementations.

[rymnc]

looks good

[netrome]

looks good

Nice, I'll proceed with the SMT tests then ☺️

[netrome]

After chatting with @xgreenx about this, we agreed that it would be less intrusive to only modify the tests for the refactor and not modify the TableWithBlueprint impl blocks to use blanket implementations through wrapper traits.

[rymnc]

not sure this pr warrants a changelog, or maybe it should be phrased better if there is a change to the public api

[netrome]

Sure, I think this warrants a changelog. The tests themselves are debatable so this entry could be skipped - but the refactor is changing the api for downstream crates reusing these tests (which we'd like to do in SRS but couldn't due to the macros making implicit assumptions that didn't work for all tables - such as assuming keys always being sized)

[netrome]

Updated the formulations in 1fad862. Let me know what you think.

[xgreenx]

Why do we need a default implementation within the RootStorageTests trait when we could have a blanket implementation?

[netrome]

Not sure I follow what you mean. Do you mean why we provide default implementations of the tests in the trait definition, as opposed to implementing them in the blanket implementation on line 890?

I think this is cleaner, since redefining the methods in the blanket implementation would cause us to have to repeat them additionally one time. And I don't see any benefit of doing it the other way around - although I have nothing against doing that way either.

Is this what you were referring to or did I misunderstand something?

[xgreenx]

Why do we need to return Box? I think you should be able to put a Sized constraint on the Key and Value. Also, you can use OwnedKey or OwnedValue instead, if it is not possible because of Rust limitation

[netrome]

Yes this was actually a problem with the old macros. We have tables where the keys aren't sized, so putting the sized constraints would break it. I don't remember if there was any issues using OwnedKey and OwnedValue - I don't think so - so I can definitely change to use it.

[netrome]

Okay looked deeper into this and the problem here is that Mappable requires that we should be able to construct and OwnedKey from a Key, but not the other way around.

pub trait Mappable {
    /// The key type is used during interaction with the storage. In most cases, it is the
    /// same as `Self::OwnedKey`.
    type Key: ?Sized + ToOwned;
    /// The owned type of the `Key` retrieving from the storage.
    type OwnedKey: From<<Self::Key as ToOwned>::Owned> + Clone;
    /// The value type is used while setting the value to the storage. In most cases, it
    /// is the same as `Self::OwnedValue`, but it is without restriction and can be
    /// used for performance optimizations.
    type Value: ?Sized + ToOwned;
    /// The owned type of the `Value` retrieving from the storage.
    type OwnedValue: From<<Self::Value as ToOwned>::Owned> + Clone;
}

And since we need references to Self::Key for e.g. insert, we'd need something like this constraint to make it work:Self::OwnedKey: AsRef<Self::Key>. I think this should hold for most tables, but not necessarily for all of them - so it is more correct to stick with the boxes here. Also while I don't like unnecessary heap allocations, these boxes are only for tests and doesn't affect the rest of the code negatively in any way.

The base branch was changed.