[spike] refactor smt_trie to be suitable for trace_decoder/node use

[0xaatif]

Our current SMT library is unsuitable for use in a client, and probably needs to be rewritten, or heavily refactored to be used in the way we'd need

Agreed on this. You mention this being medium, would you have an idea of the time it would take for a full revamping? I mentioned internal tweaks above, because Hermez and our SMT / prover backend rely on Poseidon, while we initiated discussions some time ago on possibly using Poseidon2 which is much faster, while providing roughly the same security benefits. If we wanted to do this, we'd need to decide whether this comes with dropping fully Poseidon support, or through a more modular fashion, to then support both Hermez style and the more generic/efficient cdk stack that could leverage Poseidon2.

Originally posted by @Nashtare in #761 (comment)