Measure how much regular store query is used as a safety net

[fryorcraken]

@richard-ramos added a regular store query that checks for any messages that have maybe missed.

This store query should be considered as safety net. We don't want this to be done forever as it consumes store resources.

What we want instead, is more efficient strategies such as:

• detecting disconnection and then doing a store query for the disconnected time period only (relay reliabilit and light client reliability)
• detecting missing message (e2e reliability) and querying these messages specifically.

Hence, the number of messages discovered via the regular store query is a good indicator of how efficient (or not) the other reliability strategies are.

If the regular store query finds 10 messages: these are 10 messages we should have found in another manner.
Do note that the regular store query may grab more messages than needed. It is important to only count the messages we are interested in (e.g. those we can decrypt because they are either DMs for us or messages for communities we are in).

tl;dr: count and report the number of new relevant messages found via the regular store query.

@richard-ramos can you provide the details of the regular store query change you have done?

cc @adklempner as discussed

Can't add labels, this is part of "telemetry: direct message" deliverable. cc @chair28980

[richard-ramos]

The regular store queries work like this:

• Every 30s we notify the waku layer the list of pubsub topics / content topics we're interested in https://github.com/status-im/status-go/blob/3d1695c1ea322199731ac78d3ce04b2082e2f66d/protocol/messenger_mailserver.go#L384-L413
• If there's any change in the topic list, we update the topic list the waku layer must verify
• Every minute we query the active storenode for the hashes of the messages received in the range:[ now - 1m10s, now - 10s]. https://github.com/status-im/status-go/blob/3d1695c1ea322199731ac78d3ce04b2082e2f66d/wakuv2/missing_messages.go#L90-L123
• We compare against the cache of messages, to know if we have already seen the messages or not. https://github.com/status-im/status-go/blob/3d1695c1ea322199731ac78d3ce04b2082e2f66d/wakuv2/missing_messages.go#L205-L212
• We ask for the storenodes for the content of messages we havent seen: https://github.com/status-im/status-go/blob/3d1695c1ea322199731ac78d3ce04b2082e2f66d/wakuv2/missing_messages.go#L234-L273
• We also keep track of failures to perform a query (we retry up to 3 times). If we failed to retrieve messages, then in the next minute iteration, instead of starting from now- 1m10s, we start from the last iteration initial range value.

[vpavlin]

@richard-ramos After our analysis of the code yesterday, I realized there is msgTypebeing passed to OnNewEnvelopes where the type missing represents messages received via the regular store query which seems to be enough and made it really simple:)

https://github.com/status-im/status-go/blob/e8f97045bf73c54c5819a8f00f94d8dfa194ba38/wakuv2/waku.go#L1353