🔄️ Chat message pre-fetching

[AndyScherzinger]

• New ChatMessageSyncer: fetch-and-persist core extracted from OfflineFirstChatRepository into a stateless singleton usable without an open chat; both paths share one write path.
• Room-list prefetch: rooms with advanced lastActivity (matching iOS) and unread rooms without cached messages get a background catch-up - delta fetch, or initial fetch creating the first chat block for never-opened rooms (beyond iOS). Capped at 20 rooms / 3 concurrent; skipped in battery saver / restricted background data.
• Push-triggered single-room catch-up after the notification is shown (best effort, never delays the notification).
• Notification-safe fetching: markNotificationsAsRead=0, read marker untouched, gated on the chat-keep-notifications capability.
• Chat open trusts the cache: zero network when cached messages reach lastMessage.id; proportional delta fetch otherwise; initial load never waits for the websocket.
• Hardening: chat-block reconciliation on message expiry; empty /room responses no longer cascade-delete the cache; insurance fetches anchor on the DB.
• Tests: syncer unit tests + Robolectric integration test; debug logging for logcat verification.

---

How to verify: check logcat -> expect "Catching up messages for N rooms", per-room "Background catch-up … fetched N message(s)", and the "Initial online request is skipped … until the conversation's last message" line on open. Most visible on cold opens from push notifications and throttled networks. (for logging, see commit 64a3c85). Alternatively, deploy it on the phone, wait for a while, put the phone in flight-mode, then open the chats. You should then see the unread messages.

---

Assumptions to be aware of

1. markNotificationsAsRead=0 server semantics - assumed the server keeps push notifications for background-fetched messages whenever chat-keep-notifications is announced; taken from iOS usage, not server code. If wrong, prefetching silently dismisses notifications. Most critical - please confirm.
2. Federated conversations use one consistent message-ID space - lastMessage.id from the room list is compared against local chat-block IDs; divergence via the federation proxy could wrongly skip the initial fetch (unread tail delayed to polling) or fetch redundantly (harmless). Needs a federated-room test.
3. The chat relay never replays a backlog on (re)connect - sole justification for the delta fetch at open on HPB; based on code comments/observed design, not signaling-server sources. Partial replay could leave gaps until the 2-min insurance request.
4. GET /chat long polling still works against HPB servers - the fallback when the websocket is slow/mis-detected; pre-existing behavior, unverified server-side.
5. lastActivity advances for new chat messages and its persisted copy is a valid cross-restart baseline; missed candidates degrade to pre-PR open behavior, non-message bumps cost one empty delta.
6. Message IDs strictly increase per conversation (non-contiguous is fine) - inherited chat-block premise, now leaned on harder for delta anchors.
7. Message expiration is roughly server-synchronized - block trimming tolerates clock skew (early: harmless re-fetch; late: briefly stale block, as before).
8. pushMessage.id is always a fetchable room token for TYPE_CHAT pushes (incl. federated/invite edge cases); wrong token costs one failed, caught request; the notification is unaffected.
9. NotificationWorker lifetime accommodates the synchronous catch-up - notification dispatched first, but ordering isn't formally guaranteed; an expedited separate work item is the fallback design.
10. Concurrent persists are race-safe - open-path delta, first poll, signaling and background catch-up may interleave; upserts + getConnectedChatBlocks merging + insurance requests are the intended self-healing, without formal proof. Transaction boundaries deserve review.
11. Capability cache freshness suffices for the gate - 12 h CapabilitiesWorker window; a server downgrade inside it exposes assumption 1's impact until refresh.
12. Chat API stays at v1 - CHAT_API_VERSION = 1 hardcoded in prefetch/push paths, mirroring ChatViewModel; compile-time visible, low risk.
13. 20 rooms / 3 concurrent caps are server-friendly - no rate-limit guidance existed, iOS is uncapped; too aggressive risks throttling, too conservative leaves rooms un-prefetched until the next sync (logged). Tunable constants.

🚧 TODO

• ...

🏁 Checklist

• ⛑️ Tests (unit and/or integration) are included or not needed
• 🔖 Capability is checked or not needed
• 🔙 Backport requests are created or not needed: /backport to stable-xx.x
• 📅 Milestone is set
• 🌸 PR title is meaningful (if it should be in the changelog: is it meaningful to users?)

🤖 AI (if applicable)

• The content of this PR was partly or fully generated using AI

[github-actions]

APK file: https://github.com/nextcloud/talk-android/actions/runs/30940554955/artifacts/8925256420
To test this change/fix you can simply download above APK file and install and test it in parallel to your existing Nextcloud app.
(please click on link to get QR code displayed)

[mahibi]

Most of it works really good and it's really promising 👍

However there are some major problems with the chatrelay and insurance request (see my comments).
These are edge cases what won't happen too often, but they would create permanent gaps.
For now i just identified this by code reviewing (not yet reproduced by testing).
Fixing it should not be too hard, might be just reverting some lines..

I did not finish the code review yet, so there might be more on monday (wont finish it today).

[github-actions]

APK file: https://github.com/nextcloud/talk-android/actions/runs/31505646937/artifacts/9108620109
To test this change/fix you can simply download above APK file and install and test it in parallel to your existing Nextcloud app.
(please click on link to get QR code displayed)

[mahibi]

With the current changes that i made i think the great dangerous pitfalls are avoided.
However i would like to test this branch even more tomorrow..