Revisit exposed DHT API

[daviddias]

The data types of the return values can be vastly improved + more valuable information can be provided. Currently js-ipfs is fulfilling the contract that was brought into the spec through go-ipfs + js-ipfs-api, but there is nothing stopping us from making it better.

There are also some questions with regards if we should be able to provide a block we don't have. go-ipfs let's you do it, js-ipfs wasn't letting.

Due to time constraints, I'll focus on DHT internals that are used for peerRouting and contentRouting, so that we don't touch too much at surface API and fulfil our goal of having DHT used by internals.

[daviddias]

The DHT API test suite is small too, it should be way more comprehensive, we will get it ! :)

[victorb]

Worth nothing is that the current DHT tests sometimes are not really testing anything. Looking at this file https://github.com/ipfs/interface-ipfs-core/blob/bad70aca3816b98eb88846183af404202a047055/js/src/dht.js, you can see that for example dht.provide test makes a call to provide but doesn't actually read the results, so we're not really sure if it's working or not.

[alanshaw]

@vasco-santos has done a bunch of work on this:

• Docs have been updated https://github.com/ipfs/interface-ipfs-core/blob/master/SPEC/DHT.md
• API findpeer and findprovs renamed in camel case (findPeer, findProvs)
• Core API is now returning PeerInfo objects (HTTP and CLI compatibility is retained)
• Tests have been added, updated here and in js-ipfs

Can we consider this done @daviddias?

[daviddias]

Sounds good to me!