Invest into better test tooling

[drahnr]

Materializer is our current way to spawn tests programmatically, but it's a) very docker focused b) requires containers as a consequence.

We should try to reduce complexity and allow to launch the nodes as a simple functions call fn launch<ConsensusEngineType>(config: Config) {.. } and make it re-entrant, such that a single process can launch mutliple nodes from within a single unit test.

[linear]

IPC-164 Invest into better test tooling

[raulk]

100%.

Requiring Fendermint to be Dockerized wasn't the original intention. The original goal was to replicate Lotus' itests kit for IPC. We—at Lotus—invested in creating that integration test harness a while back and it proved valuable for writing e2e tests natively without requiring containerization. Take a look at this neat test: https://github.com/filecoin-project/lotus/blob/master/itests/eth_deploy_test.go

Lotus devs use itests to get rapid feedback on their changes. Requiring a full Docker build of the codebase under test, just to be able to test it is rather silly and unproductive. We need a framework that's nimble and delightful to use, not this clunky mess.

While we do need to bite the bullet and accept some containerization—concretely for CometBFT—for everything that lives in this codebase (Fendermint, ipc-cli, Eth API), we should just drive them as libraries through their Rust APIs.

Note: there is some history here, I'm happy to read you into more context if needed, but it doesn't seem relevant.