New chat architecture + chat relay

[mahibi]

WIP

• resolve Chat relay via High-performance backend #5633

• prepare to get rid of forked ChatKit #1552 by adding a solution for developers to use Jetpack Compose for rendering of the chat messages. The goal of this PR is not to come up with a polished Compose implementation but to set the stage so that Compose can be improved over time until it finally replaces chatkit.

This PR will

• Use signaling to receive chat messages instead of long polling when hpb is used

• Introduce a regular insurance request if somehow a signaling messages did not make it through

• Change the chat architecture from an event based message handling to a state based messages handling. This change was done in this PR because adding two more ways how messages can be received (signaling and insurance request) would have made the event based messages Handling even more complex.

  • Before:
    messages were passed to ui directly from responses (as well to DB). This was necessary as the chatkit library required different processing depending on if messages from the past or future were received

  • Now:
    Received messages are just written to database no matter where they come from (initial request / request for scrolling into past /long polling / signaling / insurance request).
    Messages are observed on database to be shown in UI via flows.
    The database is the single source of truth, so no events are needed to update the ui.
    To avoid messages gaps in UI, the chat block handling is used: the flow is implemented so that always the messages from the newest chat block are emitted. For this, the database is observed for the newest chat block and whenever it changes, the messages of it are emitted.

• Implement a workaround so that chatkit library can handle the messages flow instead of the former events. For this, the adapter is cleared and all messages are added again. This may come with a minor performance loss on some devices, but as a temporary solution to migrate to Jetpack Compose + flow handling, this is the best way to go.

• Refactor and improve the Jetpack Compose code for messages that was used for the message search window to be able to handle flows. (for now it was only able to handle a single response with a chat message list)

• Add a switch for developers to use Jetpack Compose instead of chatkit. We can continue to maintain the chatkit based solution while being able to further improve the new compose solution until it's ready to replace chatkit.
  To use the compose solution for developing, just change the value of useJetpackCompose in onCreate in the ChatActvity.

• Add a new solution to automatically mark messages as read.

  • Before:
    messages were marked as read as soon as they were received.
  • Now:
    messages are marked as read until the newest message that was shown on the screen. This is transmitted whenever the user manually scrolls or when the chat is closed/brought to background.
    This change was planned for ages and it was now necessary because of the signaling handling.

• improve scope handling of the flows from database

TODO

• regular insurance requests
• handling of system messages
  • handle and translate the important ones
  • request server via insurance request for others instead to handle the message
  • ref https://github.com/nextcloud/spreed/blob/fd1807d0017d736b3d058a830f720defc670a6a0/lib/Signaling/Listener.php#L80-L101
  • ref https://github.com/nextcloud/spreed/blob/bf0f5f05e42b9d94449970c09836978650b1a514/lib/Chat/Parser/SystemMessage.php#L118
• overwrite messages from signaling with result from insurance request
  insurance request and re add them??
• architecture improvements: move more logic to viewModel
• check/fix threads handling
• unread messages inlne chat indicator
  • challenge: add it in between...
  • worst case: not possible?
• unread messages bubble
  • use latestKnownMessageIdFromSync ? -> move to viewmodel
• mark as read handling
• last read handling
• fix to get single message?
• Compose fixes/improvements for messages
  • "incoming" handling
  • avatars
  • ...
• handle temporary messages (directly via SQL query/order ?)

🏁 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]

Codacy

Lint

Type	master	PR
Warnings	99	104
Errors	0	2

SpotBugs

Category	Base	New
Bad practice	6	6
Correctness	10	10
Dodgy code	54	56
Internationalization	3	3
Malicious code vulnerability	3	3
Performance	4	4
Security	1	1
Total	81	83

Lint increased!

SpotBugs increased!