Make our tools less smart

[0xaatif]

In #375 (comment), I make the broad suggestion to decompose our "cleverer" functionality into simpler commands, e.g splitting:

• Circuit generation, caching, loading
• Making rpc calls, assembling a witness (maybe)

In #413 I regressed functionality that we don't test in CI - talking to RPC nodes and assembling an output.
This is hard to test in CI because:

• RPC nodes are precious - we don't like to expose them, and using them in CI means we have to be more careful about that.
• We can't/don't want to spin up an RPC node in CI.
• We don't want to mock a whole RPC node.

However, because this part of trace_decoder/zero_bin is all bundled together, we can't catch regressions without solving some of the above.

We can break out our Public API, and get benefits in:

• a simpler codebase
• a more testable codebase
• better user/beginner knowledge of what is going on behind the scenes

at relatively low UX cost.

[atanmarko]

RPC nodes are precious - we don't like to expose them, and using them in CI means we have to be more careful about that.
We can't/don't want to spin up an RPC node in CI.
We don't want to mock a whole RPC node.

Why not? We have already done that with the real node here, and here is the regression test that was missing for your usecase.

That aside, I agree that we should discuss functionality split.

EDIT: we now use kurtosis, before we used docker-compose to spin up test network for real regression test.

[atanmarko]

Making rpc calls, assembling a witness (maybe)

This is what rpc binary is doing at the moment.