Reimplementing download progress and open when downloaded functionality

[rapterjet2004]

• fixes reimplement Download progress #6068

🖼️ Screenshots

Screen_recording_20260420_115030.webm

🚧 TODO

• linter

🏁 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?)

[github-actions]

APK file: https://github.com/nextcloud/talk-android/actions/runs/24679084696/artifacts/6537211344
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/24893617865/artifacts/6626258416
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/24896444887/artifacts/6627536459
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/25795055404/artifacts/6968867293
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]

I rebased on master and fixed the merge conflicts.

The PR can be merged as it works and will improve UX.

However this AI review found things that should be investigated further (Could you please have a closer look and create followup PR's if necessary @rapterjet2004 ?):

• Bug – openWhenDownloadState is semantically broken for concurrent downloads

  The single shared openWhenDownloadState is computed as: "is any downloading file currently visible?". Every download worker started via downloadAndOpenFile receives a reference to this same state object. With two concurrent downloads:

  • File A is downloading, not visible → A is added to downloadingFileState
  • File B is also downloading and visible → openWhenDownloadState.value = true
  • File A finishes → checks openWhenDownloadState.value → it's true (because B is visible) → A opens unexpectedly

  The original per-message boolean was captured at tap time (when the message was visible) and held independently per download — this replacement breaks that isolation.

• Bug – SharedItemsViewHolder.trueState lifetime is wrong

  SharedItemsViewHolder.kt:62:
  val trueState = mutableStateOf(true)
  This mutableStateOf is created inside bind(), so it's recreated fresh every time the ViewHolder is recycled and rebound. If a download is in progress and the ViewHolder is rebound (user scrolls away and back), the download worker holds a stale reference to the old trueState, while
  resumeToUpdateViewsByProgress registers on the new one — the two are now disconnected.

[mahibi]

improvements for the future:

• display the actual download progress. This was done in the old implementation iirc.
• Check if implementation should be aligned with Show file upload progress and placeholder media message in chat. #6047