Document all features

[guillaumemichel]

There is a lack of feature of documentation in go-libp2p-kad-dht, which make it hard to keep the IPFS DHT spec up-to-date, and generally hard to understand what happens in the DHT implementation. We should document all features we are implementing from the start. The feature documentation should ideally live in the same repository, or alternatively on a spec/doc repository that must be kept up-to-date (e.g documentation should be added BEFORE merging the PR).

We should document the design of this implementation thoroughly.

In addition, as the Kademlia paper doesn't go much into the implementation details, we need to document them:

• Bootstrap process #47
• Client Routing Table #46
• Routing Table Maintenance #45
• Server Routing Table #44
• Priority queue implementation #22
• Reprovide Sweep Implementation zikade#40
• Implement Provider Store Module #3
• Optimize Routing Table Module #2

We should also document all non-standard Kademlia items that we add to the libp2p/IPFS implementation, for examples:

• Only add reachable peers to the routing table #53
• Diversity Filter #49
• Accelerated DHT Client zikade#39
• Optimistic Provide to replace legacy provide operation #43
• Query peerlist should contain network addresses #38
• Use in-memory transport in simulations #31
• Add TTL to Provider Record zikade#42
• Signed peer records for IPFS DHT #26
• Integrate libp2p resource manager to libp2p endpoint #25
• Add libp2p notifee to IpfsDHT #23
• Provide Interface zikade#41