Break loop in acquiring media on Safari

[robintown]

As of this week we've started seeing an issue in mobile Safari where Element Call will fail to acquire media, calling getUserMedia over and over in a loop. How this happened:

• It seems that, for whatever reason (a recent Safari update?) the browser will emit a MediaDevices 'devicechange' event whenever you call getUserMedia, even though there is no change in the devices returned by enumerateDevices.
• Then, because Element Call's reactivity happened to be a little too coarse-grained in a couple of spots (specifically, the LobbyView and MuteStates files), every 'devicechange' event would have the unintentional side effect of triggering a new call to getUserMedia. And so, the loop begins.

While it is pretty annoying that Safari has started emitting spurious 'devicechange' events, we can easily work around this situation by making our reactivity more fine-grained, breaking the loop. And this may result in performance improvements for all browsers, so, why not.

Here's the specifics of the loop:

• LobbyView calls usePreviewTracks
• usePreviewTracks has an effect which calls getUserMedia
• The browser emits a MediaDevices 'devicechange' event
• Media devices observer emits a new devices map
• MediaDevicesContext invalidates its available devices memo and returns a new devices map
• Devices map is passed to MuteStates
• MuteStates (unnecessarily) invalidates its mute states memos and returns new ones
• Mute states are passed to the LobbyView
• LobbyView (unnecessarily) invalidates its onError callback and passes a new one to usePreviewTracks
• usePreviewTracks uses the onError callback as one of the effect dependencies, so the effect runs again, and we call getUserMedia again

[robintown]

Up to the reviewer whether this needs a test, but… the failure mode is pretty idiosyncratic, and testing the lobby component is going to be painful, so I'd prefer to not!

[BillCarsonFr]

I approve but I am a bit confused by the change, and I wonder if it is not working around the real problem?

[toger5]

Nice that distinctUntilChanged can get a comparator.