bug: Align peer-exchange implementation as per spec

[chaitanyaprem]

Problem

As of now peer-exchange has been implemented differently than the spec i.e peer-exchange cache is populated based on local node's peerStore information and not by doing random walks on discv5 DHT.

per @jm-clius

The original intention of the peer exchange cache was to ring-fence the peers returned via peer exchange from the node's own peer store. In this model, the peer exchange cache would be continuously updated by random discv5 walks completely separate from the discv5 walks that populate the node's own peer store. The node would provide none of its own liveness interpretations (i.e. whether it "knows" if the returned peer is reachable or not by having tried to connect to it or not). Liveness would be a function of the discv5 built-in protocol pings and how often the cache gets refreshed with a new random walk. This would also mean that the PX node would not provide other filtering outside of what is readable in the discv5 ENR, e.g. filtering based on supported protocols determined via identify would not be possible. PX is simply a resource-restricted way to access the info in the discv5 DHT (and nothing else).

peer exchange simply being a "light" interface towards the discv5 DHT - it should have no reference to the node's internal peer store. In this case a PX cache makes sense - it is populated purely from discv5 walks (triggered probably much more regularly than every 10 mins). Probably entries should have a relatively short TTL

this would be a function of fine-tuning discv5 liveness, finding a reasonable TTL for the cache and refreshing regularly (while measuring the impact of such regular walks). Note also that PX will only probabilistically work well if it is accessed in a decentralised manner: in other words, edge nodes should not rely only on bootstrap nodes for PX results. Once they receive PX records for other relay nodes, they should also perform PX queries to those nodes. That way, with some probability, there will always be an up-to-date record for each reachable node cached somewhere.

Impact

Current approach can lead to neighbourhood surveillance attacks as explained here

Expected behavior

Align with spec the way peer-exchange cache is being populated or peers served to a client.