Fix duplicating messages and improve performance

[ShGKme]

☑️ Resolves

• Fix [Bug] Dissapearing messages / duplicated messages in chat #10027

Steps to reproduce:

1. Open ChatA
2. Switch to ChatB
3. From another tab or user send a message to ChatA
4. Wait until LeftSidebar will be updated
5. Return back to ChatA
6. You can see duplicate messages 😣

Why it happens:

1. In the messagesStore we update conversation.lastMessage in the conversation store using a new received message in the chat. Here a reference is passed to the conversationsStore's action
   

   spreed/src/store/messagesStore.js

   Lines 1065 to 1069 in d381c9c

   	if (conversation && conversation.lastMessage && lastMessage.id > conversation.lastMessage.id) {
   	context.dispatch('updateConversationLastMessage', {
   	token,
   	lastMessage,
   	})

2. In the conversationsStore then this reference is saved in the store:

spreed/src/store/conversationsStore.js

Lines 151 to 153 in d381c9c

	updateConversationLastMessage(state, { token, lastMessage }) {
	Vue.set(state.conversations[token], 'lastMessage', lastMessage)
	},

3. At this step conversationsState.conversation[token].lastMessage stores a reference to a message object from messagesStore

4. Then we patch conversationsState.conversation[token].lastMessage after receiveing new conversation on re-fetching. This mutates the object in the messages store.

spreed/src/store/conversationsStore.js

Lines 129 to 131 in d381c9c

	patchConversation(state, conversation) {
	patchObject(state.conversations[conversation.token], conversation)
	},

Another problem:

There is also conversation.lastMessage.messageParameters array. patchObject is not patching sub-arrays, so it caused almost unnecessary re-renders anyway.

🖼️ Screenshots

Green highlight = re-rendering. After PR there are more re-renderings in changed conversation items, but no re-renderings in not changed items.

🏚️ Before	🏡 After

🚧 Tasks

• Instead of patching conversation - re-assign it when the new conversation has larger lastActivity
  • Drawbacks:
    • It assumes that lastActivity is enough to know if there were any changes in the conversation
    • It could be a little bit less optimal than patching

👀 Alternatives

1. Clone lastMessage on update from messagesStore

• But there is a patching error anyway. So
  1. Adjust patchObject to handle arrays (check length and elements)
  • But it seemed to be too overkill to me

2. Adjust patchObject to handle "special" cases and list custom setters for specific keys (lastMessage)
   • But it seemed to be too overkill to me
3. Store lastMessageId instead of lastMessage in the conversation, same as lastCommonReadMessage
   • I'd like this solution, but it would require many changes. The best alternative solution for me

🏁 Checklist

• ⛑️ Tests (unit and/or integration) are included or not required
• 📘 API documentation in docs/ has been updated or is not required
• 📗 User documentation in https://github.com/nextcloud/documentation/tree/master/user_manual/talk has been updated or is not required
• 🔖 Capability is added or not needed

[nickvergessen]

I think we also need to do it when the unread counter changes, because reading a chat does not update the lastactivity

[ShGKme]

@nickvergessen do you think the change in the last commit is too much and should be replaced with just direct 'unreadMessages', 'unreadMention', 'unreadMentionDirect' checks?

Or it is fine and better to have this large update "just in case" and checks?

[ShGKme]

@nickvergessen @Antreesy If this is fine for you, I'll add some tests and ready to merge

[Antreesy]

Nothing blocking from me.
Tested with replies, works properly now

[Antreesy]

Suggested change

	if (conversation.type === CONVERSATION.TYPE.ONE_TO_ONE) {
	if (conversation.status) {

Group conversations don't have a status field, so I'm not sure if we needed that additional check before and need that now.

[ShGKme]

@nickvergessen Do you remember if there was a reason to add this check here: #9411

Except readability

[nickvergessen]

It could be that the user has no status now, but had one before. Then the event should trigger and delete the status.
Can e.g. happen when they go invisible, or when the inactive status gets purged.

That being said, it doesn't make sense with the rest of the code, so I guess no.

[nickvergessen]

But not sure it's legal to trigger the event with "undefined"

[ShGKme]

As we never have this request without includeStatus, I added emit for null status as emitting about status removal.

[ShGKme]

Updated user status update emitting.

Added test for all these cases around conversations updating and user status update emitting.

[Antreesy]

🦭

[ShGKme]

Rebased onto master and squashed

[ShGKme]

/backport to stable27