Actually track progress for send/receive

[hannahhoward]

Goals

Setup hooks with graphsync to facilitate tracking progress on the request -- this is important to get to being able to pause and resume at key increments. This sets up a bunch of the needed infrastructure for doing pause/resume and other needed facilities for retrieval.

Implementation

• Modify the channels list to make send and receive mutable. Sync it's just two numbers, rather than all of the channels list to pointers to channel state, just make these members pointers to unsigned uint64 and use sync.atomic (low level primitives for doing atomic operations on numbers). Also, move the actual data structures for channels into the channels list package and leave the types as interfaces instead
• Setup an abstraction layer for converting between events that happen in graphsync through hooks and semantic events that mean something to data transfer. this allows some seperation of graphsync logic from data transfer logic. While I didn't attempt doing it here, I think we could move everything that is actually transport-layer specific behind and interface and have all the remaining high level logic be universal (and potentially use a different transport layer on different requests so we can support multiple transports in a single data transfer instance)
• Setup all hooks to actually record data progress on a data transfer so we can support pausing at intervals for retrieval

[shannonwells]

Looks ok to me, looks like the tests are pretty complete. I had only suggestions, nothing blocking. The test instrumentation looked like a PITA to get done but it did make things pretty readable and easier to write new tests for.

[shannonwells]

Just as a sanity check it might be nice to have a parallel update test to verify the thread safety when updating sent and received.

[shannonwells]

You could reasonably combine this with the first valid incoming request test.

[shannonwells]

Consider extracting these to a well-named function for readability.