feat(lightpush): introduce ReliabilityMonitor and allow send retries

[danisharora099]

Problem

Based on #2075 and #2069,

• there is tight coupling between the reliability logic and the LightPush SDK class
• if a lightpush.send() request fails, we renew the peer directly

Solution

Based on the above problem statement, we want to do two things:

• extend and separate reliability related logic into a separate class apart from LightPush (SenderMessageMonitor)
• attempt retries on the failed peers for lightpush.send() before we actually renew the peer

Notes

• Resolves feat(lightpush): add retries to failing peers #2069
• Resolves feat: message verification and retry #2075 partially
• To be merged after feat(filter): reliability monitor as a separate class to handle reliability logic #2117 (with rebase)

Contribution checklist:

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

[github-actions]

size-limit report 📦

Path	Size	Loading time (3g)	Running time (snapdragon)	Total time
Waku node	83.56 KB (+0.44% 🔺)	1.7 s (+0.44% 🔺)	15.8 s (+1.49% 🔺)	17.4 s
Waku Simple Light Node	135.17 KB (+0.2% 🔺)	2.8 s (+0.2% 🔺)	12.1 s (+0.24% 🔺)	14.8 s
ECIES encryption	22.94 KB (0%)	459 ms (0%)	4.8 s (-32.86% 🔽)	5.2 s
Symmetric encryption	22.39 KB (0%)	448 ms (0%)	4.1 s (-18.48% 🔽)	4.5 s
DNS discovery	72.28 KB (0%)	1.5 s (0%)	10.5 s (-22.04% 🔽)	11.9 s
Peer Exchange discovery	73.79 KB (0%)	1.5 s (0%)	15.5 s (-9.09% 🔽)	17 s
Local Peer Cache Discovery	67.63 KB (0%)	1.4 s (0%)	11.9 s (+14.81% 🔺)	13.2 s
Privacy preserving protocols	74.79 KB (-0.05% 🔽)	1.5 s (-0.05% 🔽)	18.6 s (+59.84% 🔺)	20.1 s
Waku Filter	78.52 KB (+0.25% 🔺)	1.6 s (+0.25% 🔺)	9.3 s (-46.21% 🔽)	10.9 s
Waku LightPush	76.79 KB (+1.68% 🔺)	1.6 s (+1.68% 🔺)	12.7 s (+15.57% 🔺)	14.2 s
History retrieval protocols	76.02 KB (+0.1% 🔺)	1.6 s (+0.1% 🔺)	21.2 s (+81.77% 🔺)	22.7 s
Deterministic Message Hashing	7.38 KB (0%)	148 ms (0%)	3.4 s (+5.86% 🔺)	3.5 s