Use TestFiles in Bitswap test

[hannahhoward]

Goals

Align usage of TestFiles in bitswap test with IPFS tests, permit network permutations across all tests and introduce default compositions.

Implementation

The biggest thing missing here is a way to add an arbitrary files.Node to a blockstore. Currently, this only exists in the IPFS core API. I went ahead and cribbed and simplified that to support adding random files, or real files and directories.

There is now a DAGAdder which will add an arbitrary files.Node using a ipld.DAGService

Additionally the configuration is now changed so that network parameters like latency, bandwidth and jitter can all be specified as an array so that each test will be run run_count times for each permutation of file, latency, bandwidth and jitter giving us a view into how the transport behaves across a range of conditions.

This also adds seeding to random file generation to ensure deterministic behavior across tests and avoid potential race conditions.

[hannahhoward]

@adlrocha this continues the march of unifying the way these tests work

• all tests now use TestFiles (bitswap-transfer did not)
• we've established a universal mechanism for describing permutations of bandwidth, latency, test files, jitter, etc

[adlrocha]

Awesome job, @hannahhoward. I love how this is coming together. Thanks!

Two questions about this PR:

• How do permutations affect test params? Can we still specify in the same test run different latencies for different nodes in the network? (I am thinking here about experiment were want an heterogeneous network) I was trying to find an example of how to specify a bandwidth permutation and couldn't find it.
• From what I see, none of these changes break previous test params specifications, right? Just noting this because if at one point this ends up being the case, we need to update the RFC experiment compositions (that way the results of our experiments can still be replicable --specially now that we are aiming to publish the Bitswap paper 😁--).

Everything else LGTM. So feel free merge 🚀

[hannahhoward]

@adlrocha

• we did look at the question of different latencies per node and settled on the multilple global latencies become a "base latency" and the individual latencies per node become a delta to the base latency. If your base latency is zero, then the individual latencies specified are just the latencies. we need to document this
• we specifically aimed to make sure all existing experiments run as expected. @acruikshank is double checking this before we merge.

[adlrocha]

Sweet! I like the delta approach and thank you both for double checking the RFC experiments. I see that you have everything figured out 🙈

It is merging time! 🚀