FCE-423, FCE-298: Propose updated way of configuring video quality in SDKs; Re-think default activeEncodings settings in SDK; FCE-1032: Fix stopCapture

[MiloszFilimowski]

Description

• Removed configuration from RN Client
• Fixed stopCapture crash

Motivation and Context

• We agreed that for now simulcast configuration will remain hidden from the user.

How has this been tested?

Tested on iOS and Android

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to
  not work as expected)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.

[linear]

FCE-423 Propose updated way of configuring video quality in SDKs

FCE-298 Re-think default activeEncodings settings in SDK

[linear]

FCE-1032 Fix stopCapture

[mironiasty]

Looks good to go 👍

[mironiasty]

I was just thinking - do we still know that this limit applies on latest iOS version? If not, maybe we should investigate it again 🤔

[MiloszFilimowski]

Created an issue!
https://linear.app/swmansion/issue/FCE-1033

[mironiasty]

There is philosophical question: should satisfies be used, or just type variable as () => SimulcastConfig 🤔

(in the end, it does not really matter here)

[MiloszFilimowski]

In this case, it doesn't really matter. The advantage of using satisfies instead of a type is that you preserve the actual value.
So if you type is

type Something = { something: string}

and you create an object

const test = { something: 'test'} satisfies Something

You still retail the autocompletion when using test.something as "test", whereas with type annotation it's just string.

So in our case the user would now that the default value is always false.