Provide multiple STUN servers to webrtc client

[brknkfr]

• Provide multiple STUN servers to webrtc client when specified in the nextcloud backend instead of just 1 random one

[danxuliu]

As explained in the pull request for the TURN server settings the returned stunservers object resembles the RTCIceServer dictionary, but it is just data passed to the clients which each client parses on its own way.

In the case of the STUN server the url parameter must be kept too (it is used by the iOS client and the Android client; the WebUI uses the stunservers object as is). Moreover, note that the url parameter of the STUN server must be a string, not a list with a single element.

Similarly to the other pull request, composing the urls should be done in SignalingController::getSettings. In this case then it is probably not needed to have a Config::getStunSettings method, as it will just forward to Config::getStunServers. Although for simmetry with the TURN servers you could also add a Config::getStunSettings that returns a hardcoded stun: scheme, but I have no preference, as you prefer.

[nickvergessen]

In the case of the STUN server the url parameter must be kept too (it is used by the iOS client and the Android client;

Same comment here as with the turn:
We can change that and break it (if it is any good and better or clearer or ....), as there is no compatibility possible between Talk 11 (conversations api v1-3) and Talk 12 (conversations api v4) as we can not make the multiple sessions compatible with uniqueness, we can also add a breaking signaling thing on top, especially when it's just about changing a single character

[brknkfr]

Thank you for the review.

Similarly to the other pull request, composing the urls should be done in SignalingController::getSettings. In this case then it is probably not needed to have a Config::getStunSettings method, as it will just forward to Config::getStunServers. Although for simmetry with the TURN servers you could also add a Config::getStunSettings that returns a hardcoded stun: scheme, but I have no preference, as you prefer.

I completely removed Config::getStunServer and Config::getStunSettings and moved building of the urls to SignalingController::getSettings.

[danxuliu]

Like explained in the other pull request I have added a fixup to keep the format, and I have extracted the format changes to their own pull request.

Please remember to adjust the commit message after doing the fixup :-)

[brknkfr]

Unifying urls will be done #5582

[brknkfr]

Unifying urls will be done #5582

[danxuliu]

Tested* and works 👍

*Only in the WebUI, although from reading the mobile apps code it should work as well.

Thanks!