Add sending audio failure and recovery events

[avinashmidathada]

Issue #: None

Description of changes:

What?

Added two new meeting events: sendingAudioFailed to indicate a failure in sending audio packets out and sendingAudioRecovered to indicate recovery after a sendingAudioFailed event. We rely on the packetsSent metric from RTCPeerConnection's getStats() method to trigger these events, by tracking the no. of times packetsSent is 0 consecutively and storing it in connectionHealthData

The events are triggered using a new SendingAudioFailureConnectionHealthPolicy. It introduces two new properties sendingAudioFailureSamplesToConsider and sendingAudioFailureInitialWaitTimeMs inside ConnectionHealthPolicyConfiguration for configuring it's sensitivity for triggering the events. The policy also closely resembles the existing UnusableAudioWarningConnectionHealthPolicy having a similar cool down time and maximum warnings logic. I have also refactored the code in MonitorTask to create a new enactHealthPolicy() method to reduce redundancy in the health policy evaluation.

Also, added a new device to microphone drop down called No Audio which is used for integration testing.

Why?

The sendingAudioFailed event will serve both as a diagnosis tool as it's ingested into our event ingestion flow but more importantly as a callback for builders to notify the user or to prompt them to take an action such as a device change or application restart. The sendingAudioRecovered event can be used to notify user that the sending audio is now back to normal.

Testing:

• Added unit tests for all modified code with full coverage
• Added integration tests to verify that the events are being published as expected.

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

1. Run Browser Demo App in Chrome or Safari (doesn't work in Firefox)
2. Connect to a meeting with Enable event reporting checked and open the Developer Tools Console
3. After joining, change microphone input to No Audio by clicking the mic drop down
4. Wait for about 3 secs and verify that there's a log starting with Received an event: and the name of the event is sendingAudioFailed
5. Change the microphone back to the previous one or any functioning audio input
6. Wait 1 sec and verify that another similar log is printed, this time with sendingAudioRecovered

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? N/A

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

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