feat: customizable LeanIMT implementation

[brech1]

Description

This PR introduces an implementation of the Lean Incremental Merkle Tree:

• Created a generic HashedLeanIMT struct that supports arbitrary hash functions through a trait
• Implemented the LeanIMTHasher trait to allow users to provide their own hashing functions
• Implemented serialization/deserialization for all structs
• Added support for dynamic dispatch of the hash function

Related Issue(s)

• Closes lean-imt TLSNotary requirements

• Closes Create a crate for the LeanIMT  #51

Checklist

• I have read and understand the contributor guidelines and code of conduct.
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• I have run cargo fmt without getting any errors
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[sinui0]

Looks like a good base to start with!

There are some changes and features we will need but let's tackle them incrementally.

[sinui0]

This will have poor cache efficiency as each hash will be at its own heap address. I recommend flattening at least the hashes so its Vec<Vec<u8>>

[brech1]

What do you think about this?

#[cfg_attr(feature = "serde", derive(Serialize, Deserialize))]
pub struct LeanIMT<const LEAF_SIZE: usize> {
    #[serde(bound(serialize = "[u8; LEAF_SIZE]: Serialize"))]
    #[serde(bound(deserialize = "[u8; LEAF_SIZE]: Deserialize<'de>"))]
    nodes: Vec<Vec<[u8; LEAF_SIZE]>>,
}

This will fail to compile if LEAF_SIZE is greater than 32 and you're trying to do serialization/deserialization. Otherwise works just fine. It's an upper limit on LEAF_SIZE if serde is used. Imo makes sense since this is a common, safe size for a hash output.

By doing this all hashes will be stored in the vec and not at random addresses.

[sinui0]

The issue with this is that the hash size has to be known at compile time. I think its not too hard to just use dynamic indexing at runtime depending on the provided hasher.

[brech1]

Yes, you're right, we're forcing a specified output of hash function. I think we could make this temporary tradeoff in favor of performance, and then work on an update for a flattened flexible node structure, so we can have this and semaphore-rs going for the moment. I can mention this problem in the issue.

[brech1]

Happy to know your thoughts @vplasencia