fix(media): release devices and workers after the call

[Antreesy]

☑️ Resolves

• Fix regression from fix(devices): fix reactive update of the devices list #15949

fix(media): [wip] move init logic from lifecycle hooks:

• with MediaSettings always exist in background, composable is always mounted, and virtualBG code is executed, even if devices weren't used
• now only done on devices initialization

fix(media): release media devices when not used by app:

• same reason, MediaSettings is always mounted, so we can rely on scope dispose
• should be tracked manually (with subscribe/unsubscribe)

fix(media): reattach video stream, when devices already initialized

• When dialog is opened during the call, it's newly mounted; reference to video element is lost
• video stream should be attached again

fix(media): terminate background workers, when not used

• JitsiStreamBackgroundEffect worker was never terminated (can be checked on stable branches at DevTools -> Memory -> VM instances - we always have 1-2 of them before/after the call
• now detached if not used by the MediaSettings or device controllers

🖌️ UI Checklist

🖼️ Screenshots / Screencasts

No visual changes, see tab memory consumption

🚧 Tasks

• simplewebrtc -> localmedia is never stopped or disposed after leaving the call?

🏁 Checklist

• 🌏 Tested with different browsers / clients:
  • Chromium (Chrome / Edge / Opera / Brave)
  • Firefox
  • Safari
  • Talk Desktop
  • Integrations with Files sidebar and other apps
  • Not risky to browser differences / client
• ⛑️ Tests are included or not possible

[danxuliu]

Tested and works. But...

Most of this are work arounds for the real problem, which is that useDevices is being used by the local media buttons.

The devices mixin, which the useDevices composable comes from, was meant to be used only in the settings and media devices dialogs. It handled devices in a completly separate way from the devices used in the call (except for the fact that, due to historical reasons for browser compatibility, only a single device of each kind could be active at the same time, so changing the device in the dialog also changed it indirectly in the call through the MediaDevicesManager). Due to that, it requests its own audio and video streams and has its own virtual background handler to be able to show the previews.

When the composable started to be used in the local media buttons it started to request those streams when the buttons were mounted, and then it never freed them.

Although the streams are now freed they should not be requested in first place, because they are never used (and neither the virtual background) and it is just duplicating the streams used in the call.

Having said all that, given the tight timing I guess we can merge it for now (although it would be good to address the comment) and do a proper fix later...

Regarding freeing the virtual background worker that is indeed a legit fix (I would have sworn that it was loaded and then not freed for performance reasons during the initialization, although after testing it loading the model is quite fast 🤷 Not sure if I misremember, it was wrongly tested in the past, or it was indeed an issue when it was introduced back in the day but the loading time improved since then), and I think it would be good to have it too in the stable branches.

[danxuliu]

Some nitpicks, but fine even with them.

[Antreesy]

/backport to stable32