demo: prover execution improvements

[Mirko-von-Leipzig]

This PoC PR includes patches of the protocol crates which prevent generics from leaking into the node when proving.

This is of import because currently running a single proof test takes over a minute due to any proofs taking forever e.g. 1min+ on an M5, 6min+ on CI.

This occurs despite setting all dependencies to opt-level=3 because the generics involved only get set in the final binary. This means they use the optimisation level of the final binary and therefore are unoptimised.

A dissatisfactory work around is to run CI with --release + debuginfo. However this doesn't scale as any upstream of protocol would experience this. Much better would be if we could specify that a particular dependency should be optimised e.g. miden-crypto so that account grinding is faster.

Test bench

I ran

cargo test -p miden-remote-prover legacy_behaviour_with_capacity_1

as my bench. Before it took ~1 minute, after 1.7s, matching the same with --release.

What

This patches prover and tx crates to remove generics and prevent inlining. No attempt at minimsation was done - its possible that only some deltas are actually required.

Patches were AI driven.

Notably, even p3 generics were still present at the final compilation step.

I hope this is a starting point.

Results

Before:  Summary [ 946.884s] 325 tests run: 325 passed (4 slow), 1 skipped
After:   Summary [  59.671s] 325 tests run: 325 passed, 1 skipped

Compile times

Note that this should also improve compile times since generics get pushed further back into deps. There is room for improvement I think.

cc @igamigo @huitseeker @PhilippGackstatter 

[Mirko-von-Leipzig]

This can be much more specific, I just haven't bothered bisecting.

[Mirko-von-Leipzig]

I've also had the thought that maybe the maybefuture could be an issue. Since futures are state machines they're actually generics in disguise

[Mirko-von-Leipzig]

I've since opened #2004 which works around the runtime execution problem for now.

I do think this is also the cause of the slow compile times. The generics in question come all the way from the foundational p3 crates. Which means every caller of prove (maybe even execution?), pays massively for compiling the full generic stack.

The further back we can push p3, the better things will be.