feat(filter): reliability monitor as a separate class to handle reliability logic

[danisharora099]

Problem

Based on #2075, the logic to detect messages that were missed from the Filter protocol were being detected inside of the Filter SDK implementation. This leads to a tight couple of primary objective of FilterSDK, and reliability goals.

This obstacle also extends to adding further actions that might be taken with additional protocols such as Store pings, and LightPush retries for certain messages.

Solution

Decouple reliability logic into a new ReliabilityMonitor class.

Notes

• Best reviewed per commit
• Partially resolves feat: message verification and retry #2075

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	86.59 KB (+0.14% 🔺)	1.8 s (+0.14% 🔺)	1.9 s (+27.69% 🔺)	3.6 s
Waku Simple Light Node	153.89 KB (-0.13% 🔽)	3.1 s (-0.13% 🔽)	2.5 s (+28.21% 🔺)	5.5 s
ECIES encryption	22.83 KB (0%)	457 ms (0%)	551 ms (-16.26% 🔽)	1.1 s
Symmetric encryption	22.33 KB (0%)	447 ms (0%)	1.3 s (+291.26% 🔺)	1.7 s
DNS discovery	72.27 KB (0%)	1.5 s (0%)	1.6 s (+26.35% 🔺)	3.1 s
Peer Exchange discovery	73.75 KB (0%)	1.5 s (0%)	1.6 s (+93.73% 🔺)	3 s
Local Peer Cache Discovery	67.57 KB (0%)	1.4 s (0%)	2.1 s (+75.65% 🔺)	3.4 s
Privacy preserving protocols	38.91 KB (0%)	779 ms (0%)	1.1 s (+9.21% 🔺)	1.9 s
Waku Filter	81.11 KB (+0.05% 🔺)	1.7 s (+0.05% 🔺)	1.2 s (-8.33% 🔽)	2.8 s
Waku LightPush	78.6 KB (0%)	1.6 s (0%)	2.2 s (+101.38% 🔺)	3.7 s
History retrieval protocols	79.1 KB (0%)	1.6 s (0%)	2.3 s (+32.97% 🔺)	3.8 s
Deterministic Message Hashing	7.31 KB (0%)	147 ms (0%)	229 ms (-39.13% 🔽)	375 ms

[danisharora099]

superseded by #2117