This is only permitted when testing.testMode=true in config.js

- It can throw exceptions
- It doesn't return false on things which are not Number, just on things
  that are not NaN

Fixes: https://github.com/jitsi/lib-jitsi-meet/issues/2743

It doesn't get translated in the TS build, for one.

Script I used:

```python
import os

for (dirpath, dirnames, filenames) in os.walk('.'):
    if '.git' in dirpath:
        continue
    if 'node_modules' in dirpath:
        continue
    if 'dist' in dirpath:
        continue
    if 'types' in dirpath:
        continue
    for filename in filenames:
        path = os.path.join(dirpath, filename)
        if not path.endswith('.js') and not path.endswith('.ts'):
            continue
        #print(path)
        with open(path, 'r+') as f:
            #print(f)
            data = f.read()
            if '__filename' in data:
                p, ext = os.path.splitext(path)
                txt = f"'{p[2:]}'"
                print(txt)
                data = data.replace('__filename', txt)  # Assign the result back to data
                f.seek(0)
                f.write(data)
                f.truncate()
```

Aparently we call this for all tracks including for the audio tracks and it is failing with JS error. This leads to "participant unable to unmute".

Wrong check for unsupported getDisplayMedia when starting screen sharing will cause the app to never fallback to getUserMedia flow. This breaks screen sharing for all old electron clients that do not support getDisplayMedia.

Firefox added support for AV1 with DD and VP9 SVC is also working as expected in Firefox 136.

Detect if gDM support has been enabled and fallback to the previous gUM
flow otherwise.

- Lower logger level to warning
- Use nested conditions

If the enclosing Jitsi Meet app declares gDM in Electron is supported,
ignore the `electronUseGetDisplayMedia` config flag and use the gDM
flow. This facilitates having backwards compatibility since the Electron
app won't know if the deployment it's about to join has the gDM flow
support or not.

* fix(codec) Debounce the call that calc codec intersection set.
Calculate codec intersection set only once per second even when there is a burst of joins/leaves. Also, check for current codec before chaining a codec change operation when codec selection API is used.

* squash: Address review comments

The calls to RTCRtpSender.setParameters() are all chained and the current maxHeight is set after the call to setParameters is resolved. If there is another call made to setParameters before the previous one resolves, we can end up passing the wrong maxHeight resulting in the client getting stuck at an unexpected resolution. This issue can be reproduced sometimes  when the users are moving across the main and breakout rooms. TPC.setVideoCodecs() ends up pushing a wrong maxHeight for update when the previous call to setParameters hasn't resolved yet.

Don't show the misleading "user cancelled" error, there are corner cases
in which a different error can be manifested.

* feat(RTC) drop PERMISSION_PROMPT_IS_SHOWN event

It was never accurate since browsers have changed their behavior over
time and can be implemented in the application more reliably.

* squash: Update JitsiMeetJS.ts

* squash: Update hand-crafted JitsiMeetJS.d.ts

---------

Co-authored-by: Дамян Минков <damencho@jitsi.org>

Regression was introduced in 07f037e12e/. Also process encodeTime stats when H.264 is selected

The constructor for RTCSessionDescription has been deprecated - https://developer.mozilla.org/en-US/docs/Web/API/RTCSessionDescription/RTCSessionDescription.

* fix(TPC) Use videoType from 'source-add' for remote track creation.
If 'source-add' for a remote video source is received before presence for that source, videoType will default to 'camera' and the client wouldn't be able to create the virtual participant tile for rendering the desktop track.

* squash: Include the videoType for no SSRC-rewriting case.

Fixes a regression for JitsiConference::setReceiverVideoConstraint and JitsiConference::setAssumedBandwidthBps.

* feat(JingleSession) Convert Jingle->SDP directly w/o interop layer.

* Update modules/RTC/TraceablePeerConnection.js

Co-authored-by: Saúl Ibarra Corretgé <s@saghul.net>

* ref(SDP) Introduce an enum for ssrc-group semantics.
Address review comments, fix test faiilures for ssrc-rewriting case and add unit tests.

* Update modules/RTC/TraceablePeerConnection.js

Co-authored-by: Saúl Ibarra Corretgé <s@saghul.net>

* squash: Address review comments

---------

Co-authored-by: Saúl Ibarra Corretgé <s@saghul.net>

* ref(SDPDiffer) Convert to ES6 class.
Make it work directly with unified plan SDP that has multiple m-lines and add more unit tests.

* ref(xmpp) translate unified-plan SDP->Jingle directly.
Without having to run it through the SDPInterop.toPlanB cycle.

* ref(SDP) Always generate the MSID for signaling it to Jicofo.

* fix(SDPDiffer) Check explicitly for ssrc changes

* fix(SDP): Fix comments and cleanup.
Remove LOCAL_TRACK_SSRC_UPDATED event as the application ignores the event and no additional action needs to be taken when that event is fired.

* ref(SDP) Add a helper function for parsing the 'a=ssrc-group' line.

* squash: Address review comments

This was needed in older versions since the browser didn't apply maxBitrates from RTCRtpEncoderParameters on the encoder. In the newer versions this seems to be no longer the case. Also, when the codec selection API is used, we no longer renegotiate locally so if we switched codec from AV1->VP9-VP9, the AV1 bitrate setting in the SDP will still be effective resulting in a lower send resolution because of b/w limitation.

Checking for send resolution vs expected resolution was unnecessarily limiting lastN and receive resolution when local camera has issues and stops sending video. Also, do not send redundant receiver constraints on the bridge channel

* ref(QualityController) Add recovery mechanism and adjust the resolution check.
Impl a recovery mechanism for the lastN to be increased if the cpu limitation goes away and doesn't return after increasing lastN. Also, additionally improve the calculation of the expected resolution taking simulcast stream resolutions into account.

* squash: Address review comments and add more unit tests

* squash: Address review comments

* feat(quality) Add a QualityController class for runtime adjustments.
Make run time adjustments to the client when adaptive mode is enabled.

* feat: Update lastN and receive resolution to improve quality.

* squash: Address review comments

* squash: Add more logging and address review comments.

This prevents the browser from starting the camera at 60 fps wherever supported as this could drastically affect the cpu and result in poor experience.

* feat(codec-selection): Use the new codec selection API
https://github.com/w3ctag/design-reviews/issues/836. This allows the client to seamlessly switch between the codecs without having to trigger a renegotiation.
This feature is behind the flag testing.enableCodecSelectionAPI in config.js

* fix(stats): Fix local resolution stats.
The video codec for the local video sources needs to identified differently now, from the codecs field in the RTCRtpSendParameters returned by the browser. We no longer munge the remote SDP to switch to a different codec.

* feat(stats): Feed encodeTime stats for all local SSRCs to the codec selection mechanism.

* fix(codec-selection) Continue to mumge SDP for selecting H.264.

* feat(codec-selection) Make screenshare codec configurable.
If no 'screenshareCodec' is set under videoQuality or p2p settings, AV1 will be selected as default.

* squash: Address review comments

* Update modules/RTC/CodecSelection.js

Co-authored-by: Saúl Ibarra Corretgé <s@saghul.net>

* fix(codec-selection) Add codec to existing stats

---------

Co-authored-by: Saúl Ibarra Corretgé <s@saghul.net>

Fixes poor low resolution video from Spot running older electron versions when the codec changes from VP9->VP8->VP9.

This helps us in identifying the video codec associated with a local video track for codec selection torture tests.

We are already handling Safari, which provides an empty constraints
object. Handle any type of broken constraints object which doesn't have
at least a `width` and `height` properties. This is the case of Firefox
when "fingerprint resistence" is enabled.

Fixes: https://github.com/jitsi/jitsi-meet/issues/14609

Claiming there is no support for it is misleading, the user might have
called the function before the channel was initialized.

It will now happen for both local and remote tracks.

The browser is downsampling the resolution since the current default bitrates for H.264 are very conservative.