Round out diagnostic parameters

[hannahhoward]

Goals

Add some final parameters and diagnostics to the graphsync testplan, and document exactly what all the parameters do

Implementation

• Add a parameter that turns the http comparison into a libp2p over http comparison
• Add a parameter that allows you to configure graphsync's maximum number of simultaneous requests the responder will process (this is something passed to the constructor of graphsync)
• Add block diagnostics - enables precise loggings of time it takes to get to each block (block queued & block sent on responder, response received and blocked processed on the requestor)
• There are a lot of parameters, so add a README that lays out all the possible parameters you can mess with and explanations for why you might want to change some of them.

[raulk]

This will make the HTTP case run in parallel with the Graphsync nodes that haven't finished yet, thus making the results unreliable.

We could synchronize on a barrier, then call runtime.GC() to try to free resources. But I generally advise against running (a) the subject of test and (b) the control in the same process, as results won't be reliable. It's best to run these completely isolated from one another.

@aarshkshah1992 will be doing a large refactor in this test plan, turning it into a generic data transfer plan that:

• runs only one transport: graphsync, tcp, http, http-over-libp2p, raw-libp2p.
• allows you to select a muxer and a secure channel to instantiate the host with, for libp2p transports.

[hannahhoward]

@raulk a couple things:

1. There already is a generic transfer plan -- Beyond Bitswap -- I'm not sure it's the right thing for your use case, but you should at least give it a look before writing from scratch, as it actually supports much more complex data transfers (real system directories, etc)
2. If you want to write a large refactor that's fine, but I think a generic transfer plan should live outside the graphsync repo
3. I don't believe the parallel cases make that much of a difference in the over all conclusion. I've posted in thread as to why I think this and also wrote a quick hack to run the HTTP/ HTTP over libp2p seperately, which produced the same end result. I think that conclusively proves the problem is not in graphsync, and I'd like to ideally move the work out of the repo to reflect that.