perf(chat): render reactions, deletions, edits and pinned messages without waiting for the server

[AndyScherzinger]

Reactions, deletions, edits, pinning and dismissing the pinned banner only rendered once the server had acknowledged them, so every one of those taps cost a full round trip - for deletions and edits even the round trip plus the delivery of the system message that reports the change, and for the pinned banner two round trips - before anything moved on screen.

Each of them is now applied to the local database before the request goes out, and the chat renders from there. A request that fails for a transient reason (connection problem, rate limit, server error) is retried once; only a request that finally fails reverts the local change, and the revert is applied only while the local state still carries it, so a server payload that arrived meanwhile through signaling or a chat sync stays authoritative. A cancelled request - closing the chat mid-flight - reverts as well, instead of leaving the change behind forever. This follows the pattern the conversation list already uses for mark as read, favorites and archiving.

One commit per action:

• Reactions - the local write moves ahead of the request. Adding a reaction only counted HTTP 201 as success, so a server answering 200 (reaction already applied) persisted nothing at all; add now accepts 200 and 201, delete accepts 200 and 404. Failures were only logged (the Reaction*ViewState LiveData had no observers left since the Compose chat rewrite) and now reach the user as a snackbar. Operations on the same message are serialized, so two quick taps cannot overwrite each other's local write. The chips animate their count, their colors and their place in the row, so the immediate change reads as intentional rather than as a jump.
• Deletions - deleteChatMessages wrote nothing locally; the bubble only turned into a deleted message when the MESSAGE_DELETED system message came back through the sync. The message is now marked deleted locally, including dropping its attachment parameters so a deleted image stops rendering as an image, and restored from a snapshot if the request fails. HTTP 404 counts as success. The call moves from RxJava to coroutines on the way, which is what lets it reuse withRetry.
• Edits - the same wait applied, and the server's answer was used for status codes only. The new text and the edit metadata are written before the request; a server that refuses the edit (a message that is too old, for instance) restores the previous version. The confirmed version is persisted from the system message's parent, which is where the edit endpoint reports the edited message - the same place the chat sync reads it from.
• Pinning - pinning called the API, discarded the returned message and then refreshed the whole room, so the banner needed two round trips. The pinned message is written into the local conversation entry, guarded in the room list merge like the pending favorite flags, and the guard is released once the request completes so a message pinned by somebody else cannot freeze the banner.
• Dismissing the pinned banner - same shape: the dismissal is written locally and guarded, so the banner disappears on the tap instead of after the request and the room refresh that follows it.

One change is not per-action: the message list rebuild ran behind a 200 ms debounce, which held back every isolated change - each of the above included - for the full window. It now uses a leading edge throttle (Flow.throttleLatest): the first change is passed on immediately, a burst still collapses into one rebuild per window, so the reason the debounce existed is kept. Every other local edit and incoming message benefits from this too.

Behaviour is meant to be exactly as before, only mimicked locally instead of awaited.

🖼️ Screenshots

None - the UI itself does not change, only when it updates.

🚧 TODO

• Nothing outstanding

🏁 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

[AndyScherzinger]

/backport to stable-25.0.x

[github-actions]

APK file: https://github.com/nextcloud/talk-android/actions/runs/34527290870/artifacts/10172455176
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)

[github-actions]

APK file: https://github.com/nextcloud/talk-android/actions/runs/34536421911/artifacts/10175823129
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)

[github-actions]

APK file: https://github.com/nextcloud/talk-android/actions/runs/34566909089/artifacts/10186511874
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)

[github-actions]

APK file: https://github.com/nextcloud/talk-android/actions/runs/34678988533/artifacts/10293456862
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)

[github-actions]

APK file: https://github.com/nextcloud/talk-android/actions/runs/34940435207/artifacts/10385038818
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)