fix(filter): suppress subscription renewal in background mode

[xAlisher]

Problem

On mobile (Android/iOS), Waku filter subscriptions have a relay-side TTL of ~13.5 minutes (observed). When a subscription expires, the closing channel fires in subscriptionLoop, checkAndResubscribe runs, and a new wf.Subscribe() RPC is issued — waking the LTE modem from RRC Idle.

With a loaded account (50 contacts, 3 communities) this produces ~4.4 radio wakeups/hr overnight: ~144 mAh/hr of battery drain with the screen locked. Measured via dumpsys batterystats --charged on Android 13 (status-im/status-app#21045, T5b soak).

Fix

Adds backgroundMode atomic.Bool to Sub + SetBackgroundMode(bool) on Sub and FilterManager.

background=true (screen locked):

• 5s health-check ticker skipped
• Expired subscription IDs dropped without resubscription — no network I/O

background=false (foreground return):

• Immediately sends to closing to trigger resubscription
• All expired filters reconnect in one burst

Impact

	Before	After
Radio wakeups/hr (background)	~4.4	0
Drain rate, loaded account, cellular	~144 mAh/hr	~5–10 mAh/hr (est.)
Foreground latency	—	+1 reconnect burst on open

Messages sent while backgrounded are delivered via mailserver on foreground — not lost.

Usage

filterManager.SetBackgroundMode(true)   // on background
filterManager.SetBackgroundMode(false)  // on foreground — triggers resubscription

Companion status-go PR: status-im/status-go#7508

[igor-sirotin]

TLDR; This change would silently make Status deaf after 5 minutes of being in backgroundMode.

Explaining the consequences

1. There is indeed a TTL for subscriptions: it's 5 minutes here.

   • TTL is extended with either a SUBSCRIBE request, or PING, but both are blocked in this PR. If neither of these 2 is received within 5 minutes, the subscription is closed.
   • (not sure where ~13.5 minutes is coming from)

2. If a subscription died for any other reasons (e.g. remote peer is down), we should resubscribe to other nodes.

   • Each subscription's health is currently checked once in 5 seconds. But this PR drops this logic in backgroundMode=true.

So after 5 minutes of backgroundMode=true, all connected nodes will expire the subscription, and we will silently ignore this. Effect: no incoming messages.

My suggestion is:

1. Increase TTL in the fleet up to 30 minutes
2. Keep PING working, but increase the period to 10 minutes.
3. Keep the re-subscription logic.

Warning

Increasing a TTL should be consulted with AnonComms team, I'm not sure if it's a safe move.

"background mode"

I understand the intention, but I'm not sure I agree with the idea of "Background mode" in general.
Why is background mode more important than foreground? Why allow draining the battery when the app is opened?

We should look for a solution that can be always applicable.

I guess in background we could allow Status to have some delays in message delivery, but this would be implemented in a vey different way, and as a user I would expect messages to arrive instantly. And in any way, reliability should not be neglected.

Other comments

Please remove any mentions of UI/LTE and other app-level logic.
If we keep backgroundMode, then it could be mentioned once, as a use-case example. But in general, e.g. UI is not a concern of logos-delivery-go.

[jrainville]

I agree with Igor. This change would realistically make the message receiver not work.

I think we could skip this change for now and keep only the status-go change of not doing store node calls.

The changes here have a too big chance of introducing a regression where push notifications would just not work, which defeats the whole purpose of the background service.