Forced reconnections may not be noticed by the clients of other participants when the HPB is not used

If the inCall property for the participant who is reconnecting never becomes not in the call other participants would not notice that the participant in fact reconnected (as without HPB the same session ID is used) and then not update their connection with that participant (for example, to stop it if the participant is no longer publishing).

This might be fixed by the second commit (Create and destroy Peers based on call flag changes) in https://github.com/nextcloud/spreed/pull/6934

How to test

• Delay getting the users for the usersInRoom event (so if a participant leaves and quickly joins again, like in a forced reconnection, the clients will not receive the disconnected state) by adding if ($this->userId) { sleep(5); } before https://github.com/nextcloud/spreed/blob/2e26a232da65fe90042b97afeab2eb4abfbfaa51/lib/Controller/SignalingController.php#L362
• Add audio and video permissions by default in a conversation
• Start a call as a moderator
• In a private window, join the call as a guest with audio and/or video
• Wait until the connection is established (it may take a while due to the delayed signaling messages)
• In the original window, remove all permissions from the other participant

Result with this pull request

In the original window the other participant is seen as in the call, although without audio or video

Result without this pull request

In the original window the connection is lost with the other participant and never recovered

Start with the usersInRoom handling in lib/Controller/SignalingController.php around line 362, then review the second commit, “Create and destroy Peers based on call flag changes,” in pull request #6934. Reproduce the delayed signaling and permission-removal scenario described in the issue. Done means other participants notice the forced reconnection and correctly update the connection when the participant no longer publishes.