Request more data before reading in OutputController

This change is guarded behind the flag
"AudioOutputControllerRequestBeforeRead".

We currently read data from the shared memory before requesting more
data. This results in one callback size of additional latency.

With the flag enabled, this change avoids the extra latency by calling
RequestMoreData() then immediately calling Read().

This significantly reduces the amount of time available to prepare audio
samples, and also requires the audio thread to wait for audio generation
to finish. This has a high probability of causing audio glitches on
systems that ran glitch-free before, and affects all audio in Chromium.
The main goal of this CL is to enable third parties to investigate if it
is possible to reach full output latency parity with native audio
applications, and to quantify the cost of doing so. For this reason the
flag is disabled by default, and there currently is no rollout plan.

Round-trip latency test results:
- https://padenot.github.io/roundtrip-latency-tester/
- Linux using PulseAudio backend

Baseline
- AudioContext sample-rate: 48000
- Measured round-trip: 126.43750000000001ms
- Computed output latency: 50ms

With --enable-features="AudioOutputControllerRequestBeforeRead"
- AudioContext sample-rate: 48000
- Measured round-trip: 115.77083333333334ms
- Computed output latency: 30ms

The buffer size was 512, so we expected a bit more than 10ms of
 improvement.

Bug: 40125311
Change-Id: I8c5565499e7ca57ffda7b80c0f75567af88de393
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4195116
Reviewed-by: Olga Sharonova <olka@chromium.org>
Commit-Queue: Michael Wilson <mjwilson@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Thomas Guilbert <tguilbert@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1457040}