It must be served from the same origin, so we need to bypass the CDN we use for
meet.jit.si. See the code comments for the rationale on the workaround.

lib-jitsi-meet@latest

https://github.com/jitsi/jitsi-meet/issues/7911#issuecomment-714323255

Looks like the base it's still applied, so use a full URL.

We typically use a base URL for static assets using a CDN so loading the worker
from there won't work since it's a different origin. Using a URL relative to the
origin of the page will make it be loaded from the right place.

Add methods for start/stop recording in addition to the commands that we already have.

Tavram/twa

Make it a 512 square and specify its purpose as just "maskable" since this can't
go anywhere.

Through several avatar work iterations it's no longer used.

I don't know how to modify built-in MediaStreamTrack type, so ignore the error.

...so that the text is more readable in the presenter mode. Chrome by
default uses 'detail' for screen sharing. I went with the 'text' here,
because the docs[1] say "may take advantage of encoder tools that
optimize for text rendering." - whether that's good specifically for
the presenter mode I don't know. It looked good for me when tested
on Chrome.

https://www.w3.org/TR/mst-content-hint/

Since the external API now sets preferredWidth/preferredHeight for resizing the large video, we don't need to add chat width to the computed window width when the chat window is closed.
Fixes https://github.com/jitsi/jitsi-meet/issues/7889

fix(avatars) refactor preloading

Use fetch(), which gives us better control over headers.

The previous one no llonger works out of the box with RN.

The URL polyfill we were using didn't support taking a URL object in the
constructor, the updated one does.

This update doesn't touch thousands of lines of package-lock which caused a
runtime breakage on both platforms.

This reverts commit cd68c72338.

If a failure occurs while we are still setting up the UI it's possible the local
thumbnail is still null, and none of the code assumes it may be null, so skip
it.

We are off my 1KB oh well.

Fixed by patching react-native:
e7ee500660

(backport from upstream)

Fixes an issue when the video quality dialog is opened for first time
and config.videoQuality.persist is true there isn't any selected option.