Replace the `TtlStoreValue` type on cached Versions/WellKnown with background refreshes.

[pixlwave]

We've keep tripping over this expiration in different places so it's time to fix it. Some examples have been:

• Conflicts between refreshing versions and refreshing the access token Don't send a auth header when fetching the versions during a token refresh #5822 Revert "fix: Allow /versions requests to refresh the token" #5825 Don't do an authenticated /versions request in the RoomListService builder #5853 feat(sdk): Support refreshing the access token in Client::fetch_server_versions #5916
• Changes to the well-known's rtc_foci taking up to 7 days to be picked up by clients (admittedly we should be using the newer CS API endpoint for this now, but that would still involve caching a value) which became even more apparent after fix(sdk): Use the server name from the user id as a fallback URL for fetching the well-known info #5996 which had no immediate effect unless the cache was cleared.
• Discovered today: SyncServiceBuilder::build can fail with network related errors such as DNS resolution/Timeouts/Temporary server errors when checking server support for thread subscriptions. If we want good offline support in the SDK (and to handle poor connections gracefully) a Client and its associated services should really not be making network requests to be built and supply already cached data.

The solution (already been discussed with @bnjbvr a week or two ago) would be to remove TtlStoreValue and it's STALE_THRESHOLD and always return the cached value. Alongside this, we would need a mechanism that would make the relevant API calls in the background, caching any valid responses so that the next read is up to date. These background refreshes should ideally wait until any sync loops are running and up-to-date to avoid slowing down initial syncs and at the very least should be scheduled every time a Client is created (although ideally using something like SyncService::start to schedule the refreshes would help long-lived Clients to stay more up to date as apps get backgrounded and foregrounded).

[bnjbvr]

Sounds like a solid plan, thanks for writing an issue!

These background refreshes should ideally wait until any sync loops are running and up-to-date to avoid slowing down initial syncs and at the very least should be scheduled every time a Client is created (although ideally using something like SyncService::start to schedule the refreshes would help long-lived Clients to stay more up to date as apps get backgrounded and foregrounded).

This entangles two logically unrelated features just a bit too much, so we'd need to find a better cutting point. Perhaps after the client has been created, it would do this in the background? This would race with the start of the sync service, but it might be problematic only if the race's winner is the sync service starting — in which case, the SSS request might fail and be retried later with the correct server information. Does it make sense?

[pixlwave]

wait until any sync loops are running and up-to-date to avoid slowing down initial syncs

I think this is the only important part and (imo) is the definition of "background" in this instance. The rest of it is just me having ideas about potential solutions without having a solid enough grasp of the SDK architecture to be confident about the reality of those ideas.

[bnjbvr]

We've discussed this in the Rust SDK meeting, and we think that a Good Enough™ (a 80/20) first solution would be to spawn the request in the background, when building the ClientBuilder. If it's entirely clear that this is slowing down sync (it's not entirely clear to me now, because network is likely not slower than the i/o happening on the server to materialize a SSS response), then we can find better ways to implement this:

• spawn the request after N seconds, with N > 30; likely a good 90/10 solution
• listen to the SyncService state somehow, and wait for the SSS to be stabilized, before spawning this background request

How does it sound @pixlwave? Do you have evidence based on your previous experience that this could slow down sync?

[pixlwave]

To be honest I'm only thinking about making sure we don't move further away from the idea that a sliding sync catch-up should be measured in ms rather than seconds and part of that was making sure that that first 20-room window was the only request in flight (given that on a mobile device, the network can range from multi-gigabit on 5G to under 100kb/s on Edge). Maybe the whole idea has changed since then 🤷‍♂️

If it helps, it would be trivial on the app-side if the SDK didn't automatically spawn the requests but rather just exposed a Client::refresh_caches method, then we could make sure we call it in our SyncService state listener the first time that hits .running?

Either way, up to you – ultimately the change we're most interested in on the app-side is the removal of the cache expiry so however it happens we'll be happy 😁