Fix Routing Table Refresh after we have a SearchByKadId RPC

[aarshkshah1992]

We should have a SearchByKadId RPC which allows us to search for a key in the network using it's DHT Id in the XOR space and then revisit how we refresh the Routing Table/have better tests.

TODO

• Have a SearchByKadId RPC.

• Rewrite the refresh logic in DHT & Routing Table to use the new RPC.

• Remove the GenRandPeerId in go-libp2p-kbucket function which can ONLY produce upto maxCpls.

• Stop refreshing once we stop filling buckets because we are searching for CPLs that might not even have peers in the network. (Stop refreshing once we stop filling buckets #550)
  PR at Routing Table Refresh manager #601.

• Have a solid integration test and a TestGround that ensures the Refresh works correctly.

Also,

Nice to have:

• Collapse empty buckets to make the state easy to reason about (Collapse empty buckets when possible. go-libp2p-kbucket#72).
  PR at: NPeersForCpl and collapse empty buckets go-libp2p-kbucket#77.

• Test refreshes on an empty RT returns an appropriate error Test that querying with an empty routing table returns the correct error #555.
  PR at Routing Table Refresh manager #601.

[aarshkshah1992]

@Stebalien @aschmahmann.

[aschmahmann]

Thanks for filing the issue on this, I thought we'd already filed this when we first hacked in the GenRandPeerID function but I guess not.

Worth noting that the outlier here isn't really the bucket refreshing but the FindPeer RPC. Tagging libp2p/go-libp2p#784 as a reminder.

[aarshkshah1992]

@aschmahmann I am not sure what you mean.

I understand that the GetClosestPeers RPC needs to take a kadId and move away from using the FindPeer RPC. However, how is the FindPeer issue linked to what we are trying to do here ?

[aarshkshah1992]

@jacobheun For the 0.6 milestone.