Do a pass on mpt_trie

[0xaatif]

• Use alloy-trie's logic for calculating hashes efficiently.
  • Let's devote some time to trie panics with cannot convert a slice of length 29 to FixedBytes<32> with small data alloy-rs/trie#9 (comment), and then take it on.
• Remove the stats and debug modules - I don't think we use them.
• I'm skeptical of the Arc<Node>s everywhere - I'd prefer they were boxed, but we get a perf penalty in constructing dummy tries for our tests (I don't think this is a good reason)
• Refactor the Nibbles type
• Drop the StandardTrie types and traits c.f refactor: simplify mpt_trie's API #400
• Better interface types

[Nashtare]

Remove the stats and debug modules - I don't think we use them

This is not accurate. We heavily use them when debugging trie discrepancies yielding KernelPanic on the prover side.
We leverage the tools defined here that rely on these modules.

[BGluth]

I'm skeptical of the Arc<Node>s everywhere - I'd prefer they were boxed, but we get a perf penalty in constructing dummy tries for our tests (I don't think this is a good reason)

I'm trying to remember the exact reason why I ended up adding the Arc<_>s. It's obviously not a race condition within the library, but I remember convincing myself at the time that it was needed. You might be able to replace it with an Rc, but we really want to make sure that we keep that CoW setup for performance reasons.

Use alloy-trie's logic for calculating hashes efficiently.

Yeah give it a look, but two things:

• Make sure their logic works with our Hash node types.
• Check that it lazily caches & calculates node hashes (very likely does).

[BGluth]

Also just to clarify from the issue title, are you thinking about removing mpt_trie entirely?

[0xaatif]

Also just to clarify from the issue title, are you thinking about removing mpt_trie entirely?

No, I think our trie library offers something unique that other libraries don't :) I just want to make it simpler if possible, c.f #400