feat: curate peers shared over px protocol

[alrevuelta]

closes #1521

• Remove the peer exchange discv5 loop and reuse the peers discovered via discv5 by the peer manager. ref
• Curate peers shared over peer exchange, sharing only reachable peers feat: curate peers shared over peerexchange #1521 (peers that are connected (or were connected in the past) and come from discv5). This helps the requester to not waste time with unreachable peers.
• Fix issue were duplicated peers were returned by peer exchange protocol within the same rpc call. (eg if 2 peers were requested, both could be the same)
• Update px cache every x time, to avoid attacks such as graph learning. With this, a peer requesting peers via px will get at max MaxPeersCacheSize peers (see this).

Beyond unit tests, can be tested with:

./build/wakunode2 --dns-discovery=true --dns-discovery-url=enrtree://AOGECG2SPND25EEFMAJ5WF3KSGJNSGV356DSTL2YVLLZWIV6SAYBM@prod.nodes.status.im --discv5-discovery=true --discv5-enr-auto-update=True --nodekey=161c2836197e8918d7eb1039758423795f0dc697a018ed55d5931aa9b0e5efb3 --peer-exchange

./build/wakunode2 \
--tcp-port=30305 \
--ports-shift=1 \
--peer-exchange-node=/ip4/127.0.0.1/tcp/60000/p2p/16Uiu2HAm2ZuRHGZUzG6JGJeY1nGKHXLGrQYnZ7mZToymHtFfYFFf

[Ivansete-status]

Shall we use () as it is a verb?

Suggested change

	if remotePeerInfo.enr.isSome:
	if remotePeerInfo.enr.isSome():

[Ivansete-status]

LGTM! 🥇

[jm-clius]

Approach looks good, though I have a question about race conditions.

[jm-clius]

Wouldn't this cause a race condition between when someone is querying the cache and the heartbeat is cleaning the cache in order to populate it again? I would suggest that the cache being populated and the one queried be different with an atomic swap between the two after the former is populated.

[alrevuelta]

Indeed, totally missed that

should be fixed here: 910afc5

[vpavlin]

Is there a way to limit these "arbitrary" sleeps in our tests and rather check for the state (e.g. in a loop with some smaller sleep duration) or would that be an overkill? IMO that could potentially speed up some test runs and at the same time make them more resilient in case the node is slower.

[alrevuelta]

indeed, totally agree that in some tests we should follow this pattern, waitFor instead of arbitrary sleep. we would still need a timeout but ofc tests would finish before, and we can cut some time.

perhaps not for this specific test, but will take it into account for further tests/refactors thanks!

[jm-clius]

Thanks! LGTM now.