Fix using signaling session ID instead of Nextcloud session ID

[danxuliu]

CallParticipantModels provide the signaling session ID and the Nextcloud session ID. When the internal signaling server is used both IDs are the same, but not with the external signaling server. The session ID in the participant and peer data provided by the Nextcloud server is the Nextcloud session ID, so no participant or peer data was found in the CallView components when the external signaling server was used, as the data was looked for using the signaling session ID.

This does not seem to have been a problem, though, as generally the CallParticipantModels provide the needed data from the signaling messages, and the components only fall back to the participant or peer data when the data is not found in the models. This seems to be the case only with SIP participants, as the fall back to the peer data was initially introduced when SIP support was added, and then the fall back to the participant data was introduced in a later fix. However... given that even when it was introduced the peer data was already using the signaling session ID but indexed using the Nextcloud session ID the fallbacks may not have even worked 🤔 Anyway, I could not test with SIP participants, so this pull request just fixes the usage of the session ID, independently of whether it is actually needed or not 🤷

Besides that, note that the guest name store can not be used by guest themselves, as the guest display name is set from the participant data, which is not available to guest users. But again the display name is expected to be provided by the model, and got from other places only as a fallback. The VideoVue component falls back to both the guest store and the peer data, but the Screen and ReactionToaster only fall back to the guest store, so it would not work when the current participant is a guest and the UI shows the screen or reaction of other guests. However, if the fallback is needed only for SIP participants then it should not be a problem, as they can not share the screen nor send a reaction.

Independently of all that, guestName in LocalVideo is unused since NcAvatar was replaced by AvatarWrapper, so the computed property and all the related code was removed.

How to test

• Remove the code to get the participant name, actor type and user id from the model in VideoVue, Screen and ReactionToaster so only the fallbacks are used (and for a thorough testing, leave a single fallback when there are several in the same method; be careful, as the peer data itself falls back to the participant data when a user ID is provided, so you may get data even if you were not expecting it, which can be a bit puzzling)
• Create a public conversation
• Start a call
• In a private window, join the conversation as a guest and set a name
• Join the call
• Share the screen and send reactions

Result with this pull request

The name and avatar of the guest user is properly shown in the original window for the video, screen and reactions (note that the name and avatar of the registered user may not be shown in the guest window if the data is not got from the model)

Result without this pull request

The name and avatar of the guest user is not set or is a generic one

[Antreesy]

Makes sense in general, tested with guest participants

[nickvergessen]

/backport to stable30

[nickvergessen]

conflicts?

[danxuliu]

Backport to 29 and 28?

[Antreesy]

Should be possible to backport, and fine by me, but I don't think it's necessary (unless other PR based on this is also need to be backported)