Content discovery, timeouts, and retrying

[koivunej]

We should retry if either the dht query finds no results or none of our existing peers have or give us the block.

I'll PR the test case soon enough.

Expected: we should retry the content discovery while trying the old and new peers. In the best case scenario we'd support the latest bitswap spec but we should also handle timeouts to wantlist items.

[koivunej]

(I've been a bit burdened with other work.) Perhaps the idea of timeouts is all wrong given the messaging (not rpc) based approach envisioned in bitswap spec. The #452 simple case can be fixed by having the peer2 (who will be put_block'd) fulfill the want to peer1 after peer2.put_block. Now, this will allow to keep a simple 1.0 implementation which doesn't really poll peers, but need to check if other implementations are treating this as a "remember wantlist while connected" setup which might imply a bit of trust.