feat: rocksdb storage for AccountTree and NullifierTree by default

[drahnr]

Currently we only use LargeSmt<Memory> with the Memory backend. This is not very useful in practice, the entire purpose of LargeSmt is having a disk backed Smt implementation.

This PR will ensure we have the rocksdb feature enabled in miden-crypto until it's extracted per #1218 .

How it's done

We use the dependency feature unification of cargo to ensure we depend on miden-crypto with the rocksdb feature enabled. However, this incurs both a hefty penalty on compile times by default, compiling rocksdb-sys and additional CI dependencies, which leads to disabling it by default.

CI

Since rocksdb comes with some overhead / CI time / cache we only want to run it whenever we change OR link against system level libraries statically.
NOT part of this PR since I am unsure of the best path.

Extras

Some additional type aliases are used to avoid lengthy types.

[drahnr]

Requires 0xMiden/crypto#613 to be merged, otherwise we might get a panic.

[Mirko-von-Leipzig]

Could you add a comment on why this is necessary?

[drahnr]

This plays into CI and not compiling rocksdb by default on CI (see absence of it in the list), but only if relevant files changed, i.e. anything in accounts. That was the rough idea to limit the CI roundtrip time to those PRs where it matters. I am aware this is far from optimal and I'd prefer to do it differently (always compile).

[Mirko-von-Leipzig]

I'm not loving the CI complexity.

Is the goal not to always have this enabled? When would we run a node without this once its working? I would imagine that CI caching should keep the compile times in check or no?

[drahnr]

I really hate the CI crap that's part of the PR.
The CI caching should keep the CI times in check, but right now rocksdb also compiles it's C/CXX dependency, which takes a while.

The rationale: It takes a while to compile rocksdb. If it's cached, it re-claims a good chunk of cache size. I don't necessarily want to cache this at all. I'd preferably link statically against host libraries (at least in CI), but this has proven itself to be fragile (llvm compiler version fun).

I am very open to suggestions how to handle this.

Also: Not a fan of GHA, it's a constrained dumpsterfire.

[drahnr]

I simplified it to use host libraries. As said earlier, no good solutions, only trade-offs.

[drahnr]

Host libraries are too old on debian 🫠

[Mirko-von-Leipzig]

Is there a roadmap or point-in-time when we would always have this enabled?