Refactor test cases code.

[adlrocha]

For the sake of development speed and rapid result explorations, there is a lot of redundant code in test cases. This needs to be fixed before it becomes "technical debt".

[hannahhoward]

Hi @adlrocha -- I am going to start working on this shortly

Wanted to run some stuff by you before I do:
As I see it, the current test cases are broken up covers a few different concerns:

• Type of host constructed (currently raw tcp socket, Bitswap + Libp2p, full IPFS host)
• Node topology (full connection between nodes, partial connection with passive nodes, etc)
• Data fetching method (normal vs waves, UnixFX vs Graphsync)

My thinking is this:

• the only thing that should constitute a truly different type of test case is the type of host
• we out to be able to parameterize the sparse and waves test with the general IPFS transfer test, based on supporting paramaterized node topology and fetching methods
• I'd actually like to match fetching method only cover who asks who for what and when -- and move the graphsync test to be a raw libp2p+graphsync test. That means:
• TCP = raw transfer,
• Raw Bitswap = Walk method in utils (though I think we should use https://github.com/ipfs/go-merkledag/blob/master/merkledag.go#L377 which will enable us to add concurrency),
• Graphsync = graphsync.Request
• IPFS = UnixFS().Get

All of these tests share a ton of common steps, that I'd like to refactor to be as deduplicated as possible:

• setting up a data store
• putting data in the datastore for seeders
• building a libp2p host (all except TCP)
• connecting nodes in some kind of topology
• fetching in some fashion from the other nodes
• waiting for things to finish

I'd love it if the test cases themselves were quite short -- right now they're hundreds of lines and hard to read to understand what's going on, plus they copy each other a lot.

[hannahhoward]

I will of course update the compositions in the rfc directories as needed in the PR

[adlrocha]

That'd be awesome, @hannahhoward! Everything you suggest SGTM.

Actually, this is something I've been looking to do myself for a while, but never find the time. I keep copy-pasting and patching test cases to evaluate the prototypes but I never invest the time on structuring the code right (so the tests are completely unreadable by themselves). Thanks!