feat(lightpush): peer management for protocols

[danisharora099]

Problem

For Filter and LightPush, every time a new LP request/new subscription is created, getPeers() is called -- this is called every time which gives us a new set of peers to use for each request/subscription.

Further, we wish to discard a peer if it fails, and renew it with another peer. This is not trivial to do if we rely on getting a new set of peers each time.

Solution

This PR tackles it for LightPush:

• A list of peers is constantly maintained for lightpush equal to numPeersToUse
• If there is a node that fails for whatever reason, that peer is disconnected, and a new peer is introduced to the list

Notes

• Related to https://github.com/waku-org/js-waku/issues/2002

Contribution checklist:

• [ ] covered by unit tests;
• [ ] covered by e2e test;
• [ ] add ! in title if breaks public API;

[github-actions[bot]]

size-limit report 📦

Path	Size	Loading time (3g)	Running time (snapdragon)	Total time
Waku node	183.21 KB (+0.87% 🔺)	3.7 s (+0.87% 🔺)	13.1 s (-21.67% 🔽)	16.8 s
Waku Simple Light Node	183.19 KB (+0.9% 🔺)	3.7 s (+0.9% 🔺)	21 s (+17.38% 🔺)	24.7 s
ECIES encryption	23.12 KB (0%)	463 ms (0%)	3.4 s (-40.64% 🔽)	3.8 s
Symmetric encryption	22.58 KB (0%)	452 ms (0%)	4 s (-31.2% 🔽)	4.5 s
DNS discovery	72.49 KB (0%)	1.5 s (0%)	7.7 s (-24.07% 🔽)	9.1 s
Peer Exchange discovery	74.15 KB (0%)	1.5 s (0%)	10.7 s (+37.17% 🔺)	12.1 s
Local Peer Cache Discovery	67.68 KB (0%)	1.4 s (0%)	11.5 s (-5.72% 🔽)	12.9 s
Privacy preserving protocols	38.87 KB (0%)	778 ms (0%)	8.5 s (-0.85% 🔽)	9.2 s
Waku Filter	112.58 KB (+0.6% 🔺)	2.3 s (+0.6% 🔺)	15.3 s (+17.96% 🔺)	17.6 s
Waku LightPush	111.1 KB (+0.65% 🔺)	2.3 s (+0.65% 🔺)	14.9 s (-15.58% 🔽)	17.1 s
History retrieval protocols	111.67 KB (+0.69% 🔺)	2.3 s (+0.69% 🔺)	24.2 s (+113.55% 🔺)	26.4 s
Deterministic Message Hashing	7.29 KB (0%)	146 ms (0%)	1.1 s (-37.26% 🔽)	1.2 s