Bithack

*BitHack* makes a few changes to the way our BitSwap implementation work. From an API standpoint, the biggest change is the addition of `GetBlocks`.  `GetBlock` has been changed to be a special case call of `GetBlocks`. When `GetBlocks` is called, the keys that are requested are sent to another goroutine through a channel, where the actual requests are handled.

When a set of keys are requested, BitSwap will add them all to the wantlist, and the find providers for the first key in the list. It will then send the wantlist to those found providers.
The main bitswap loop now contains a 'timeout ticker', when it ticks, bitswap will find providers for every single key left on the wantlist and send the wantlist out to them, this is the 'plan B' as we hope that our initial request succeeds, saving us the bandwidth. This operation could be optimized to ensure only sending wantlist to a peer once per tick.

`ReceiveMessage` also was changed. Previously it would *always* return a message, which looked to me like it would cause an infinite loop of messaging between a set of peers. Im surprised we never experienced anything bad because of it.

To take advantage of this new behaviour, I modified the DAGReader to use GetBlocks to retrieve blocks for reading.
> why did this change from defer close(blocksCh) ?

This function has been around the world and back again. It's merely a coincidence that it resembles the previous version.

> why did it change?

There was an intermediate state in the design where it was necessary to unsubscribe from keys on exit.

> why is it still this way now?

~~I left it this way since, in this particular function, this is a more "stable" syntax. That is, in future changes, we're more likely to add another deferred statement than remove the one that's there now. In that case, rather than hopping back and forth between `defer func() { foo(); bar(); }()` and `defer foo()`, we can just leave it as is.~~

discomfort with 

> isn't it still necessary to unsubscribe on exit?

oh s***. you're right. we either need to...

a) provide pubsub with a fully-buffered channel so the pub sub registry never blocks on this receiver
b) or with a partially-buffered channel, prove that we have unsubscribed from keys before the registry has had a chance to fill the buffer

> are you going to fix this?

yeah. here: 0d76b487a16cb0e82bcaa094282909a6ff3684a0