avoid getting webrtc into underrun

[xianshijing-lk]

Before this patch, our Rust code will not send silence frames until it missed 10 frames consecutively. This becomes a problem as it will get webrtc into underrun.

From my tests using C++ code, the latency gets quite a lot if we start sending audio right after the underrun, and I am seeing around 200ms (or even 500ms) more latency depending on how soon we send the audio right after the runderrun.

Note, the underrun can recover if we send the silence for some time.

As example, without this PR if we send audio 500ms after the underun, I got
(Note, the network latency is quite a lot since I am using a VPN on a public wifi in Asia, and the server in Chicago)

Full Duplex Latency (A->B->A) Statistics

Samples: 100
Min: 1028.92 ms
Avg: 1164.50 ms
P50: 1159.24 ms
P95: 1238.49 ms
P99: 1258.87 ms
Max: 1258.87 ms

========================================
One-way Latency (A->B) Statistics

Samples: 100
Min: 457.08 ms
Avg: 514.64 ms
P50: 518.29 ms
P95: 530.22 ms
P99: 538.46 ms
Max: 538.46 ms

========================================
One-way Latency (B->A) Statistics

Samples: 100
Min: 509.38 ms
Avg: 649.79 ms
P50: 639.62 ms
P95: 730.73 ms
P99: 741.46 ms
Max: 741.46 ms

With this PR, I got:

========================================
Full Duplex Latency (A->B->A) Statistics

Samples: 100
Min: 930.37 ms
Avg: 983.10 ms
P50: 980.41 ms
P95: 1008.79 ms
P99: 1058.21 ms
Max: 1058.21 ms

========================================
One-way Latency (A->B) Statistics

Samples: 100
Min: 468.65 ms
Avg: 518.12 ms
P50: 519.16 ms
P95: 529.26 ms
P99: 547.65 ms
Max: 547.65 ms

========================================
One-way Latency (B->A) Statistics

Samples: 100
Min: 429.44 ms
Avg: 464.91 ms
P50: 460.70 ms
P95: 480.72 ms
P99: 520.24 ms
Max: 520.24 ms

[theomonnom]

lgtm!

[xianshijing-lk]

Thanks @theomonnom, landing now, lets run some tests before making a new python release