docs: clarify FIND_NODE response for DHT-client nodes

[achingbrain]

If a node receives a FIND_NODE RPC call with a peer ID, it should return only closer DHT servers, unless it knows the peer ID in question, in which case it should include it, even if it is not a DHT server.

[guillaumemichel]

There is so far no mention that DHT clients must be routable (in the case they are looked for), and whether DHT clients should be known by (the closest) DHT servers. This addition isn't required for clients to function correctly in the case clients only request to the network, and don't use ADD_PROVIDER. So I am not sure it would be relevant to add this to the spec.

However, since go-libp2p-kad-dht is doing it, and it may be expected from all nodes in the Amino DHT, it would be good to spec this somewhere, along with how DHT clients routing is expected to work. We may have to create an Amino DHT spec at some point to add specific DHT protocol improvements such as the ones described here.

[achingbrain]

There is so far no mention that DHT clients must be routable

The spec makes explicit reference to publicly and non-publicly routable nodes in the Client and server mode section, all this PR does is try to clarify when they are or are not returned. Unless you mean something different?

[guillaumemichel]

I meant that the spec describes how DHT servers should keep track of each other (routing table), but not how DHT clients should be tracked. Let's assume:

• C is a DHT Client
• S is the DHT Server that is the closest to C
• There is no guarantee that S knows about C, because DHT servers aren't expected to store DHT Client addresses

Returning a DHT Client's addresses along with the closest DHT server peers is a hack to make DHT Clients routable/discoverable, but there is no guarantee that it will work. Amino is making use of this hack, but other libp2p networks don't necessarily need to have their DHT Clients routable/discoverable.