* debugapi/peer.go - the AddPeer method on kademlia was called after connecting to the peer. this is legacy from the full topology implementation and is incorrect in this case. The resulting behavior would be that the peer would be connected to, then would be added to the known peers list, instead of both known and connect lists. So the kademlia would try to iterate in manage but the peer would never show up in the known peers list, so would never show up in the iterator.
* it could be, that under certain circumstances that this peer would be gossiped to the node from another node, eventually triggering adding the peer through AddPeer, resulting in it being in the knownPeers slice. It is difficult to say what would be the behavior in such case, since AddPeer does not guarantee trying to connect to such a node, so we cannot guarantee in such case that the peer will ever shown in the connectedPeers list
* kademlia.go - moved the addition of a peer to the connect peers list after connect has finished. this is to prevent a data race when we try to connect to a peer, but it has already dialed in but was not yet added to the kademlia (the Connected callback was not yet called). In this case the peer should also be added to the connected peers list. This call is of no harm, since duplicates are not allowed as part of pslice guarantees (they are skipped and not added)
* kademlia.go - add peer to known peers slice on dial in - the problem was that a peer has dialed in, but was never known to us, resulting in an inconsistency in the kademlia
node.go - peer should not be disconnected from when AddPeer fails in the case of kademlia (since AddPeer doesn't guarantee a connection)