🔁 Screen shares should be automatically reconnected if they fail

When a participant joins with audio or video the other participants establish a connection with that participant, and if the connection fails it is automatically reconnected. However, when a participant shares the screen that participant establishes the connection with all the other participants; if those connections fail or are never established they are not automatically reconnected. Screen share connections should behave like audio/video connections instead.

Currently there is no way for other participants to know if a participant is sharing the screen or not; this is why the participant who is sharing the screen is the one establishing the connection with the rest of participants. The final goal would be that the other participants are the ones establishing the connection when a participant shares the screen. That would require a coordinated change in all the clients, but it would be possible to add automatic reconnection of failed screen shares without it.

Steps to implement:

• Add a value to the call flags for screen sharing
  • Check uses of the call flags in all the clients to ensure that the new value will not break anything (it should not, but... :-) )
• Clients will still wait for the participant sharing the screen to establish the connection, but if they did not in 10 seconds it can be assumed that the connection failed and they can try to establish it (similar to what is done with audio/video connections without HPB)
  • Similarly, they can retry a connection if a connection ends but the other participant is still sharing the screen
  • This might require changes in the HPB, as it expects screen sharing offers to be sent rather than to be requested
  • This might require changes in the WebUI (when the HPB is not used) to handle the incoming connections
  • Mobile clients may not implement the automatic reconnection and work just as before
• Change all clients to establish a connection with a participant that is sharing the screen, rather than waiting for that participant to establish the connection with them
  • Mobile clients are backwards compatible with previous Nextcloud versions, so they may need a capability or something similar to know if they should establish the screen sharing connection or wait for the other end to do it

Start with the call flags in lib/Participant.php and the WebRTC connection logic in src/utils/webrtc/webrtc.js, then inspect their uses across the WebUI, HPB, and mobile clients. Determine how screen-share offers and incoming connections currently flow. Done means failed or missing screen-share connections retry automatically while preserving compatibility with clients that do not implement the change.