This is a feature of WebRTC that's [not standardized][1] and only
supported by libwebrtc. Since there's no support in jingle for passing
this capability from one peer to another, we're currently hard-coding
this option into both the local candidate and also the remote candidate
so they can use it.

But I'm trying to call a user that isn't using WebRTC, and renomination
is causing the call to stay in "connecting..." state for 10 or 20
seconds, sometimes longer, while both sides wait for the other to
nominate something based on their individual beliefs about the standards
they're using.

Removing this seems to make connecting relatively instantaneous.

If we want to reintroduce this feature, we should probably make a XEP so
the peers can negotiate honestly about it, and only use it if both sides
truely support the feature.

[1]: https://datatracker.ietf.org/doc/html/draft-thatcher-ice-renomination-01

fixes #3978

trying to play 'none' ringtone resulted in the default ring tone being played

fixes #3972 fixes #3801 fixes #3931

the 'strings' resource on transifex was in the internal 'Android 1' format
instead of the more modern 'Android 2' format.

This according to transifex support caused some weird issues…

The only work around (apparently) was to create a new resource (now call
main-strings) and use that instead.

I hope we didn’t mess anything up in the process.

Let's be extra careful with the next release

Conversations used to deduplicate disco queries based on their hash.
However that relies on the first query to go through (device to actually
respond) and to respond properly (hash matches).

Creating a proper retry behaviour for this is actually quite challanging.
(which one would you try next, how long do you wait?)