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	83.2 KB (+0.28% 🔺)	1.7 s (+0.28% 🔺)	13.6 s (+86.5% 🔺)	15.3 s
Waku Simple Light Node	134.91 KB (+0.05% 🔺)	2.7 s (+0.05% 🔺)	18.2 s (+21.51% 🔺)	20.9 s
ECIES encryption	22.94 KB (0%)	459 ms (0%)	5.8 s (+51.59% 🔺)	6.3 s
Symmetric encryption	22.39 KB (0%)	448 ms (0%)	4.4 s (-14.97% 🔽)	4.9 s
DNS discovery	72.28 KB (0%)	1.5 s (0%)	10.6 s (+26.97% 🔺)	12.1 s
Peer Exchange discovery	73.79 KB (0%)	1.5 s (0%)	11.8 s (+67.86% 🔺)	13.3 s
Local Peer Cache Discovery	67.63 KB (0%)	1.4 s (0%)	13 s (+28.82% 🔺)	14.4 s
Privacy preserving protocols	74.82 KB (+0.04% 🔺)	1.5 s (+0.04% 🔺)	12.9 s (+40.71% 🔺)	14.4 s
Waku Filter	78.33 KB (+0.34% 🔺)	1.6 s (+0.34% 🔺)	15.5 s (+36.4% 🔺)	17 s
Waku LightPush	75.53 KB (-0.08% 🔽)	1.6 s (-0.08% 🔽)	14.4 s (+8.89% 🔺)	15.9 s
History retrieval protocols	75.95 KB (-0.02% 🔽)	1.6 s (-0.02% 🔽)	9.2 s (-34.6% 🔽)	10.7 s
Deterministic Message Hashing	7.38 KB (0%)	148 ms (0%)	1.1 s (-48.58% 🔽)	1.2 s

[weboko]

since it is a new entity - can you, please, add UT for it? it can be a follow up PR

[weboko]

let's, please, check how it works in dogfooding app

[danisharora099]

superseding the work on this PR with #2127

[weboko]

@danisharora099 just to double check is this PR main and #2127 should be dropped or vice versa?

[danisharora099]

@danisharora099 just to double check is this PR main and #2127 should be dropped or vice versa?

We will use this PR instead.

[weboko]

nit: to disposal

this.monitorManager = ReliabilityManager.create();
this.reliabilityMonitor = this.monitorManager.create();

this.filter = new Filter (this.reliabilityManager);

...

stop() {
  this.monitorManager.dispose();
}