feat: unsubscribe in case invalid push requests are received from server

[chaitanyaprem]

Problem

There are few scenarios noticed during dogfooding that Filter-Push is received for subscriptions LightNode no longer has.

One scenario where this could happen is

1. Filter Subscribe for contentTopics C1, C2 and C3 to node1.
2. Internet is disconnected and reconnected again.
3. Now C1 and C2 are subscribed to node2 whereas C3 is still subscribed to node1
4. Now node1 thinks we are subscribed to C1 and c2 still as we keep sending Filter-Ping.

Suggested solution

When we receive an invalid push request, send a unsubscribe request to that peer for that specific contentTopic.

Alternatives considered

When we regain connectivity, send unsubscribeAll to all peers with which we had filter subscriptions before connectivityLoss.

Acceptance criteria

Have a test to validate this scenario.

[chaitanyaprem]

cc @waku-org/js-waku-developers @danisharora099.
This is something that will have to be implemented in Filter SDK.

Happy to hear if there are any other alternative solutions for this.

[danisharora099]

Internet is disconnected and reconnected again.
Now C1 and C2 are subscribed to node2 whereas C3 is still subscribed to node1

I'm curious to understand how this happens where when the internet connectivity is lost, two content topics have subscriptions with the node, but subscription with one content topic is still left?
Another perspective: why does the connected and subscribed node lose subscriptions with certain content topics, while we regain connectivity?

[chaitanyaprem]

Internet is disconnected and reconnected again.
Now C1 and C2 are subscribed to node2 whereas C3 is still subscribed to node1

I'm curious to understand how this happens where when the internet connectivity is lost, two content topics have subscriptions with the node, but subscription with one content topic is still left? Another perspective: why does the connected and subscribed node lose subscriptions with certain content topics, while we regain connectivity?

Well, this could happen if after reconnection the same peer(which before disconnection was used for all 3) but was selected for only C3. So serviceNode/peer thinks we still have subscription for all 3 as we keep pinging the node.
Hence it keeps forwarding messages for C1 and C2 as well.

Only way i can think of to handle this is to send unsubscribe to those contentTopics for which we are receiving messages and we are not subscribed to for that peer. i.e in this case on receiving messages for C2 from the peer, we have to unsubscribe C2 towards that peer.