DHT Refactoring

[whyrusleeping]

As @jbenet is quick to mention, the DHT could use a bit more abstraction, this issue will be a place to discuss those changes.

[whyrusleeping]

We have a good number of methods that make a single one hop request to a single given peer, i have most of these methods suffixed with 'Single' but it would be nice to come up with a name that more clearly describes their purpose and refactor them to have a similar interface. and potentially put them all in their own file.

These methods are:

findProvidersSingle
findPeerSingle
getValueSingle
putValueToNetwork

[whyrusleeping]

The clustering idea needs to be abstracted out more, and some pleasant interface should be made. Maybe having a channel to read peers from would be the easiest interface to satisfy, then the object can automatically move to more distant peers as it runs out of closer ones.

[whyrusleeping]

@jbenet what do you think of having a peer type for the dht that contains context about routing levels? Something like a LeveledPeer, that (for coral type routing scenarios) contains information about which level of cluster its in

[jbenet]

All this sgtm. there's also a dht interface lying around somewhere in an issue (that both standard kademlia, coral, etc can implement for the general "routing-over-dht" dht/routing.go code.