[Fix]VideoRenderers being added in multiple superviews

[ipavlidakis]

🎯 Goal

Ensure that video tracks are always visible.

📝 Summary

There are a two underline issues resulting in this bug:

• When a user stops publishing video (that is translated as track muted for BE) we remove the track from our array and then we stop receiving events about it whenever the user decides to re-enable their camera.
• The visibility observation was being added on the view ONLY when the participant had video. When the user reenables their video the view doesn't fire the geometry calculation causing the view to not trigger the track visibility change.
• For local track we rely on 2 input signals to disable the track a) we disable locally the track we have a reference to, b) we send a mute request to the SFU which replies with an event that updates the participant to hasVideo:false. Due to this we have multiple instances of VideoRendererView trying to use the cached VideoRenderer.

🛠 Implementation

• We now remove the unpublished track only in the case where the reason is different that muted
• We apply the visibility modifier on all renderer views regardless of the user's publishing video.
• We now have an optimisation in the VideoRendererView, where if the participant doesn't need to showVideo we render a dummy VideoRenderer and not trying to use the cached value.

🧪 Manual Testing Notes

• Enter a call from web and iOS (with more than 6 participants).
• Try all layouts and verify they work.
• Start sharing from web and ensure that the local track is visible in all layouts.

☑️ Contributor Checklist

• I have signed the Stream CLA (required)
• This change follows zero ⚠️ policy (required)
• This change should receive manual QA
• Changelog is updated with client-facing changes
• New code is covered by unit tests
• Comparison screenshots added for visual changes
• Affected documentation updated (Docusaurus, tutorial, CMS)

[martinmitrevski]

Nice find 👍 So now we remove the track in 2 cases:

• when participant leaves the call
• when the track is unpublished for other reasons than muting

[martinmitrevski]

Indentation here and on the next one

[ipavlidakis]

I actually did that in purpose to help with the readability of the calculations. I can roll it back if you want though.

[sonarqubecloud]

Quality Gate passed

The SonarCloud Quality Gate passed, but some issues were introduced.

4 New issues
0 Security Hotspots
66.4% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud