Stop using the Lotus itest framework for integration tests #109
Description
What
I want to raise awareness that this repo's use of Lotus itest framework for integration tests makes updates of modules dependencies quite difficult, or at minimum tied to lotus also updating sudependencies. These tests work by spinning up simulation nodes of lotus and lotus miner as well as filclient in a single process within a go test. Because these nodes are all in the same process, they are all essentially locked to the same go module dependency graph in order to compile. This essentially means that not only is filclient locked to its Lotus version, but it's locked to all of Lotus's sub dependencies. This means for example the entire libp2p and transfer stack must be on the same version as Lotus
Proposed solution
Bedrock has the same problem in Boost. I've filed an issue here -- filecoin-project/boost#990 -- my proposed solution is something based on docker, though the specifics aren't ironed out. I think once we solve it in Boost we can try to port a similar situation to filclient, for feel free to try your own approaches.