feat: Use turn.delta.chat as fallback TURN server (#7382)

[iequidoo]

Note that if the server doesn't support IMAP METADATA, the fallback TURN server isn't used. I didn't get why the code is written this way, i.e. create_fallback_ice_servers() is only called if the server supports METADATA, do we want to change this?

Looks working, tested with a nine profile and non-chatmail too.
For testing with the release DC Desktop apply 8f6ce74 also, otherwise the "Call" button isn't even shown.

Close #7382

[r10s]

Note that if the server doesn't support IMAP METADATA, the fallback TURN server isn't used. I didn't get why the code is written this way, i.e. create_fallback_ice_servers() is only called if the server supports METADATA, do we want to change this?

i agree, this looks wrong.

IMAP METADATA is not supported by all server (iirc, e.g. it is not enabled by default dovecot installs) - and i do not see a good reason why core should not pass default TURN server to UI in that case. esp. as this will result in bad UX and bad debuggability, as we still cannot know a TURN server is returned in all cases.

the only reason that come to mind is that the code gets too complexity, and if IMAP METADATA is supported by >99% of servers - but i doubt both, cc @link2xt will have more insights

[link2xt]

do we want to change this?

It's a bug, if IMAP METADATA is not supported we should use the fallback server as well.

[iequidoo]

It's a bug, if IMAP METADATA is not supported we should use the fallback server as well.

Pushed a fix for this as well.

[Simon-Laux]

this pr includes unrelated changes, namely it seems to revert #7285

maybe a mistake that happened during rebase? or sth. left over from development?

[iequidoo]

this pr includes unrelated changes, namely it seems to revert #7285

maybe a mistake that happened during rebase? or sth. left over from development?

Removed the reverting commit. I added it initially because w/o it one can't test this PR in the release version of DC Desktop, the "Call" button isn't even shown.

[Simon-Laux]

Looks good, but better wait for another review because I didn't took the time to fully understand it.

[iequidoo]

Finally this looks working for me, i just didn't know how to test it the right way. It's not necessary to force using TURN via the WebRTC API, even having devices in the same network just do smth like:

iptables -A INPUT -s 192.168.1.x -j DROP
iptables -A OUTPUT -d 192.168.1.x -j DROP
ip6tables -A INPUT -s 2800:a4:673:bd00:3e9e:5639:93df:xxxx -j DROP
ip6tables -A OUTPUT -d 2800:a4:673:bd00:3e9e:5639:93df:xxxx -j DROP

Then after an unsuccessful direct connection the offering side will use TURN and the accepting side -- STUN:
Selected candidate pair: local: srflx (STUN) 190.134.202.123 => remote: relay (TURN) 46.224.39.230.

Better if somebody else tests this too, but it's ready for review.

[link2xt]

STUN server can be just removed, if there is TURN server you don't need STUN even to get non-relay candidates. But maybe let's keep it in case we want to shutdown turn.delta.chat for some reason.

[iequidoo]

Yes, let's keep it as is, i tried to remove "nine.testrun.org" fallback STUN, but anyway i see that the accepting side goes to a STUN server of my internet provider (190.134.202.123), so at least for me removal of our fallback STUN changes nothing

[link2xt]

cargo-deny CI is fixable with rebase