Room list: listen to call event to check number of participants

[florianduros]

This PR makes the room list item to listen to CallEvent#Participants event to check the number of the participants and display the video icon if necessary.

Why is it needed?
In #32663, the EC tests are failing: https://e2e-32663--matrix-react-sdk.netlify.app/#?q=s%3Afailed:

• Element Call › Switching rooms › should be able to switch rooms and have the call persist
• Element Call › Switching rooms › should be able to start a call, close it via PiP, and start again in the same room
• Element Call › Switching rooms › should be able to start a call, close it via PiP, and start again in a different room

When testing manually, the video icon is displayed however only because it's relying on the notification events. Notifications triggers a re-render, check the number of participants in the call and displays the icon.
Clearing the excessive re-renders makes the e2e failed because they don't fire a notification. The call state event is fired (0 participants in the room) and ... nothing, no event that a new participant has joined the call.

[toger5]

This looks sensible.
Thanks.

[robintown]

I would like the CallStore to keep its pretty limited responsibilities — it should track which calls are in which rooms, and not a whole lot else. Adding more events kind of obscures its purpose.

Therefore if a consumer is interested in a call's metadata, they should subscribe to events directly on the relevant Call object as needed. This keeps the reactivity fine-grained and explicit. Does that make sense to you?

[toger5]

I would like the CallStore to keep its pretty limited responsibilities — it should track which calls are in which rooms, and not a whole lot else. Adding more events kind of obscures its purpose.

Therefore if a consumer is interested in a call's metadata, they should subscribe to events directly on the relevant Call object as needed. This keeps the reactivity fine-grained and explicit. Does that make sense to you?

I can relate to this take. We will end up with a very large amount of subscriptions however.
since we would need to track each room manually and maybe even do so at numerous places in the UI dependent how we use it. Centralising "all call store" events (that we need for the room list) and all "call" events that we need when showing a more detailed call info page seems like a sensible architecture to me.

Overall I am wondering if we can simplify the EW code a lot by moving to js-sdk primitives like the matrixRtcSessionManger directly. (and also expose RTCSession instead of the wrapped Call model)

I do expect us to look into this eventually (probably when we consider changing the jitsi impl to also just be matrixRTC or when dropping legacy calls or making them matrixRTC complient as well) and then I would like to give this a very thorough evaluation how we want the call api to look like.

TLDR: I am okay with how it is done to reduce friction but robins approach is also the one I would like a little bit more. (A "little" because I am seeing a risk of misusing the api and ending up with a lot of subscriptions accidently)

[dbkr]

I did wonder about this as it seemed a bit redundant for it to just pass the messages straight through, I concluded that maybe consistency is best if it's listening for some events from here, but I do still think it's a bit unnecessary.

[toger5]

Is this really what we do when using trackListener?
Will the tracker be automatically be cleaned up? Or will we end up checking if for all manually off emitters if they are still connected and only call off in the dispose step on the ones still connected?

[florianduros]

The tracker cleans up the listeners when the view model is disposed. It's not tied to the lifecycle of the Call object