Samples: Fit the RTP transceiver rolling buffers to fit the set of sample frames

[sirknightj]

Issue #, if available:
-N/A

What was changed?

• Rolling buffer configuration for audio and video streams in the sample Master WebRTC client application was updated to better fit the sample frames, for H.264, H.265 [video] and opus [audio].
• This uses the new optional configuration API introduced in Memory Optimization - Rolling Buffer #2077.

Why was it changed?

• Reduce the memory usage of the sample application. The default rolling buffers are too big, causing extra RTP packets to get stored for the retransmitter (nacks) that the other peer would have considered too old to get retransmitted.
  • Refer to Rolling buffer size enhancements, bug fix, and unit tests #2081 for details on how to check how far from the top of the buffer (old) the other peer requests retransmits for.

How was it changed?

• Reduced the bitrate in the rolling buffer parameter for the sample frames.
• Added calls to configure transceiver rolling buffers with the new parameters, for audio and video separately.

What testing was done for the changes?

• Ran the updated master sample Ingenic T31, M1 Mac and Ubuntu EC2 and checked the playback (more than the past 3 seconds when the rolling buffer fills up) with the JS and to check for regressions.
• Added some print statements when the rolling buffer fills up (not committed) to confirm it takes longer than 3 seconds.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[sirknightj]

Note: In the other samples this is not set, meaning default values are used. Since CALLOC is used for the sample configuration, these values are 0 everywhere else. Calling configureTransceiverRollingBuffer with 0's (or also not calling it at all) will use the default values.