Fix fast meeting join race condition

[nainkunal933]

Issue #: In Safari, if the user navigates from preview screen to the meeting very quickly the application runs into a race condition. The preview screen is responsible for calling navigator.mediaDevices.getUserMedia and in Safari this call seems to be slower than FireFox and Chrome. This issue is only reproducible in Safari.

When the user redirects from authentication page to preview page, the following code is executed via AsyncScheduler: https://github.com/aws/amazon-chime-sdk-js/blob/main/demos/browser/app/meetingV2/meetingV2.ts#L3403-L3492.

Inside this code includes the call to capture media devices via await this.openAudioInputFromSelectionAndPreview();.

If the user navigates to meeting quickly, the code linked above is not done executing and it causes a race condition where the MonitorTask is initialized as part of meeting join and starts processing the metrics. RTC metrics reports the audio bit rate to be 0 which is recorded as a sendingAudioFailed event.

Description of changes: Adding an openAudioInputFromSelection call to make sure that there is an audio input device as the user enters the meeting.

Testing:

Can these tested using a demo application? Please provide reproducible step-by-step instructions.

1. Join a meeting in Safari
2. In the preview window, select the join button
3. The user should not see a sendingAudioFailed event in the console.

Without this change, the meeting roster will not appear and there will be a sendingAudioFailed event logged in the console.

Checklist:

1. Have you successfully run npm run build:release locally? Yes

2. Do you add, modify, or delete public API definitions? If yes, has that been reviewed and approved? No

3. Do you change the wire protocol, e.g. the request method? If yes, has that been reviewed and approved? No

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.