fix(conversation): adjust broadcasted data between tabs

[Antreesy]

☑️ Resolves

Fix #12548

• pass options: { all } to leader tab, when force refresh;
• do not fetch anything on secondary tabs, pass message to force refresh via broadcast channel;
• do not fetch anything on leaving conversation;
• broadcast federation invites count to secondary tabs;

🖌️ UI Checklist

🖼️ Screenshots / Screencasts

🏡 After

Screencast.from.21.06.2024.15.58.27.webm

🏁 Checklist

• 🌏 Tested with Chrome, Firefox and Safari or should not be risky to browser differences
• 🖥️ Tested with Desktop client or should not be risky for it
• 🖌️ Design was reviewed, approved or inspired by the design team
• ⛑️ Tests are included or not possible
• 📗 User documentation in https://github.com/nextcloud/documentation/tree/master/user_manual/talk has been updated or is not required

[DorraJaouad]

Solution looks good

[DorraJaouad]

Tested

[danxuliu]

A room signaling message with roomid: "" is sent by the signaling server when the current participant leaves a room (as a response to the message sent by the client, note that should-refresh-conversations is not directly triggered by _doLeaveRoom as seems to be implied from the second commit message, it is indirectly triggered). However, that message can be sent by the signaling server too to the active participants of a room if that room is deleted.

If the participant is a registered user the client will also receive a roomlist signaling message with type: "disinvite", which will cause a redirection to spreed/not-found. However, if the particiant is a guest no other signaling message will be received to notify the client about the current room being deleted.

Due to that, if should-refresh-conversations is not emitted when a room signaling message with roomid: "" is sent by the signaling server the UI is not immediately updated for guests when public conversations are deleted (although it will be updated at most after 30 seconds, but that smells like legacy code that might be cleaned at some point).

Similarly, if a video verification conversation is deleted by the moderator without even joining the conversation the UI for the guest will never reflect that the conversation is deleted. If the moderator joins the conversation and then leaves (which automatically deletes the conversation) it will, but only because when the moderator leaves a roomlist message with type: "update" will be sent, which will also cause the conversation to be fetched again (and as the conversation is automatically deleted it will no longer exist once the request reaches the server, so the UI will be properly updated on the response).

Would it be possible to emit should-refresh-conversations even when roomid: "" but ignore the event in those places in which an update is not needed in that case? Or maybe emit a different event when roomid: "" that could be explicitly listened to if needed?

[Antreesy]

Thanks for the review, @danxuliu ! It is indeed more complex problem than it was expected by me 👀

We have 4 emiiters of emit('should-refresh-conversations' event in total (all in signaling.js), so I assume we can provide each emit with a meaningful payload to distinct it on frontend.
My suggestion is to handle it separately. I'll drop the blocking commit for now and open an issue

Aligned with Daniel, as blocking commit is removed

[Antreesy]

/backport to stable29