feat: changes for optimizing filter ping

[chaitanyaprem]

Description

Implementing #1099 , realized that there are some issues wrt approach taken in #1048

Following are the issues being addressed/to be addressed:

1. For each subscription towards same peer, pings are sent which is unnecessary traffic periodically
2. There is no check that if a Filter ping fails , a susbcribe is done what if it already chooses another peer for which we have subscription against? (tracked fix: avoid possible reuse of same peers during Filter resubscribe by Filter API #1104)

Taking an approach to not send an actual ping via Filter Subscription Ping API, rather check status of last ping. And trying to no refactor code much, so that we can check results faster.

Note: Tests are still pending.

Approach/Impementation Details:

• Have a separate go-routine that collates unique peers from all subscriptions and sends a ping once in 5 seconds to each peer
• If the ping fails, the same is notified in the subscription Closing channel(indicating that this subscription is closing..could use better wording i guess)
• Filter API layer would then use this indication to take further actions such as resubscribing to another peer (Note that there is still a possible issue indicate in point-2 above that needs to be fixed)
• Going forward, this same indication can be used to take actions such as initiate storev3 queries for this subscription based and compare with local message cache and fetch any missed messages from store node.

Pending Items:

• Unit tests to validate new logic
• fix: avoid possible reuse of same peers during Filter resubscribe by Filter API #1104
• Update Filter API test to subscribe to a new peer

[status-im-auto]

Jenkins Builds

Click to see older builds (10)

❔	Commit	#️⃣	Finished (UTC)	Duration	Platform	Result
✔️	c636567	#1	2024-05-16 08:39:46	~2 min	nix-flake	📄log
✔️	1bf42c6	#2	2024-05-16 08:42:28	~2 min	nix-flake	📄log
✔️	cbec661	#3	2024-05-17 05:40:43	~2 min	nix-flake	📄log
✔️	d20f81d	#4	2024-05-17 06:05:08	~2 min	nix-flake	📄log
✔️	6ed5c06	#5	2024-05-17 06:22:41	~2 min	nix-flake	📄log
✔️	f02cbbd	#6	2024-05-17 11:06:58	~2 min	nix-flake	📄log
✔️	efac861	#7	2024-05-21 09:04:08	~2 min	nix-flake	📄log
✔️	e5772ac	#8	2024-05-21 09:35:33	~2 min	nix-flake	📄log
✔️	adf19ce	#9	2024-05-21 09:52:33	~2 min	nix-flake	📄log
✔️	8c542e1	#10	2024-05-21 10:28:23	~2 min	nix-flake	📄log

❔	Commit	#️⃣	Finished (UTC)	Duration	Platform	Result
✔️	629125f	#11	2024-05-21 23:04:26	~3 min	nix-flake	📄log
✔️	20c7bf5	#12	2024-05-22 06:11:37	~2 min	nix-flake	📄log

[kaichaosun]

I haven't think too much about peer management. My general feeling is that, one periodic loop to check health and close unhealthy ones, another periodic loop ensure the quoted connection requirements are properly provisioned.

[kaichaosun]

A few nitpicks, overall LGTM 👍