Log info about ignored options when unmuting track

[lukasIO]

I'm a bit torn on this – at least in its current state.

The problem is that e.g. setMicrophoneEnabled will only consider the CaptureOptions and TrackPublishOptions passed to it the first time it actually results in publishing a track. Subsequent calls only mute/unmute.
That's why it seems reasonable to log an info about the options being ignored.
However this might get a bit noisy in cases where the same (initial) options get passed each time.

A couple of ideas that would make it better than the current proposal:

• deep compare of options (for capture options this will get a bit more tricky as we'll have to unwrap the constraints passed to the track itself) and only log when they're not the same as the ones set on the track
• store captureOptions also on the track and do the same shallow compare that we do for TrackPublishOptions in this PR

[changeset-bot]

⚠️ No Changeset found

Latest commit: 34ba0cf

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

size-limit report 📦

Path	Size
dist/livekit-client.esm.mjs	80.83 KB (+0.01% 🔺)
dist/livekit-client.umd.js	86.77 KB (+0.02% 🔺)

[1egoman]

I am definitely not an expert on this code path, but assuming the api interface must stay the same, initially the two approaches that come to mind are:

1. Do a shallow reference check / warn like you are doing now, maybe with a note like "to get rid of this warning, pass the same reference in each time"
2. Send some sort of update to the active track telling it that its options should change - ideally it is done in such a way where all the option "leaves" as they make their way through the abstraction layers are individually reference-equality checked, which ends up implicitly implementing a "deep equals" type of mechanism.

I don't particularly like the explicit deep equality check option IMO, because if larger / non easily equality checked things like class instances eventually end up in the options, at best it could get a lot slower, and at worst it would silently break because somebody wasn't aware of this behavior.

Maybe this is something to add to the client 3.0 doc though - IMO it seems like it would be ideal if there were two methods instead - one that initialized the track and one that mutes / unmutes, with assertions to ensure they are used in the right way.