insertDTMF() can race with stopping or sender.replaceTrack(null)

[jan-ivar]

The insertDTMF playout task says to: "start playout of tone for [[Duration]] ms on the associated RTP media stream", without checking whether it is able to send. This can race with replaceTrack(null) or even stopping (which happens before stopped).

[jan-ivar]

Even with #2861, it's still not super-deterministic: temporarily setting replaceTrack(null) should stop the tone immediately based on existing "stop sending" language I presume. However, whether the next tone (and the remaining sequence) goes off or not, seems entirely up to to timing. E.g. if the app calls replaceTrack(audioTrack) again with some non-null audio track before the next tone is set to go off, then tones will continue, otherwise they won't. Thoughts?

[jan-ivar]

It would probably be better if tones never resumed in this case.