fix(publicip): retry fetching information on failure

[yorah]

Description

The public IP information is fetched only once per tunnel-up (onTunnelUp → RunOnce). That single fetch runs seconds after reconnection, when the tunnel is often still flaky, and if it fails, the data stays empty until the next tunnel-up, potentially days later, with /v1/publicip/ip serving {"public_ip":""} the whole time (breaking Homepage widgets and monitoring, as reported in #3300).

Real-world example (v3.41.1, WireGuard/AirVPN): after a ~25 min provider outage, the healthcheck-triggered reconnect succeeded, but the tunnel-up fetch timed out on all four sources (all fetchers failed: … Client.Timeout exceeded). The tunnel stabilized seconds later, yet the IP stayed empty for days because nothing ever retried.

This PR makes the fetch self-healing:

• on failure, a retry is scheduled with exponential backoff: 10s, doubling, capped at 5 minutes, until success;
• a new tunnel-up trigger supersedes any pending retry and resets the backoff;
• retries stop when the tunnel goes down (ClearData) or if the public IP feature is disabled.

No new settings (no wiki change needed), and zero extra API load when fetches succeed. Includes two unit tests (pass with -race); golangci-lint clean; docker build . succeeds.

Issue

Fixes #3300 (also previously reported as #1855, #2848).

Assertions

• I am aware that any changes to settings should be reflected in the wiki

[qdm12]

Thanks for the contribution. Unfortunately that's a lot of added complexity for a bandaid fix which does not address the true issue here.

That single fetch runs seconds after reconnection, when the tunnel is often still flaky

It should not be "flaky". The "full" healthcheck (TLS+DNS check) passed before fetching the public ip information, so the tunnel should be already working well. If there was an outage or unhealthy connections beforehand, it shouldn't matter for this new connection.

On top of this, in issue #3300 you can see there are other issues such as cannot get version information so focusing exclusively on the public ip part is not good enough. We should address the root cause, mostly related to the http client timeout.

If this is still unresolved with the latest image which should have a 15s timeout (double check with log timestamps), we can proceed with the bandaid fix for the public ip but with a fixed number of retries (3) and no retry wait time, to keep code simple - if it still fails after 3 x 15s retries, it probably won't work ever.

[yorah]

Thanks for your feedback!

To be more precise, the few times I observed this behavior was when AirVPN had an outage. And I think the "flakiness" was on their side (due to everyone trying to reconnect to the serve rthat just went up at the same time).

I will re-check my logs when I get back home, and report back. I remember I am using 3.41.1, which I believe is the last release.

[qdm12]

try the latest image It's about 7 months ahead of v3.41.1 and not the same as v3 or v3.41.1