Restore Video Call Visualizer on enqueuing if it is running

[ykyivskyi-gl]

What was solved?
This PR restores Video Call Visualizer on enqueuing if it is running

Release notes:

• Feature
• Ignore
• Release notes (Is it clear from the description here?)
• Migration guide (If changes are needed for integrator already using the SDK - what needs to be communicated? Add underneath please)

Additional info:

• Is the feature sufficiently tested? All tests fixed? Necessary unit, acceptance, snapshots added? Check that at least new public classes & methods are covered with unit tests
• Did you add logging beneficial for troubleshooting of customer issues?
• Did you add new logging? We would like the logging between platforms to be similar. Refer to Logging from iOS SDKs → Things to consider for newly added logs in Confluence for more information.

[EgorovEI]

From the added logic I see that if there is ongoing CV without video and resolveEngagementState is called, snackbar will not be shown. But our diagrams requires this. But maybe I missed something.
It would also be good to add unit test for showing snackbar in this case. If it is not added yet.

[ykyivskyi-gl]

@EgorovEI It seems that it's either restoring Video or snackbar. handleOngoingCallVisualizer checks if it's video CV so try to restore Video if it is chat/audio/messaging - show snackbar. Here is the test that checks if snackbar is showing

ios-sdk-widgets/GliaWidgetsTests/Sources/Glia/GliaTests+EngagementLauncher.swift

Line 118 in 86d4e1b

func test_testEnqueuingWhenCallVisualizerIsActiveShouldShowSnackbar() throws {

[EgorovEI]

@EgorovEI It seems that it's either restoring Video or snackbar. handleOngoingCallVisualizer checks if it's video CV so try to restore Video if it is chat/audio/messaging - show snackbar. Here is the test that checks if snackbar is showing

ios-sdk-widgets/GliaWidgetsTests/Sources/Glia/GliaTests+EngagementLauncher.swift

Line 118 in 86d4e1b

func test_testEnqueuingWhenCallVisualizerIsActiveShouldShowSnackbar() throws {

handleOngoingCallVisualizer checks if videoCall engagement kind was initiated by EngagementLauncher, not existing CV video. So If there is non-video CV and videoCall is chosen, then it tries to restore CV video screen and fails, because engagement.mediaStreams.video is nil.

[ykyivskyi-gl]

@EgorovEI basically was right that there is an issue with restoring non video CV engagement with video engagement type selected. During fixing this issue I decided to add a test for every restoring CV engagement case(audio, chat, video engagement) it may be a bit redundant but will keep us safe as there is different behavior for video and non-video engagements.

Thanks Egor!

[ykyivskyi-gl]

As Android team does not throw error here and it there is no sense to do it we decided to align it between platforms.

[ykyivskyi-gl]

I have not come up with better solution so these checks happen twice: here and in Call Visualizer. It has to be done inside Call Visualizer as it is internal method and may be used somewhere else.