Update stereo opus test to expect upmixing.

Update the test that sends and receives a local mono track with opus
that on the remote side the channelCount is 2 because the opus decoder
performs upmixing.

This strange behavior is option 1) discussed in
w3c/webrtc-pc#3010. This allows for some
optimization and simplifications which aids in virtual audio SSRC use
case of flip-flopping between mono and stereo signals on the wire and
not having to re-initialize the decoder (which could cause glitches).

The vibe from the November Virtual Interim
(https://www.w3.org/2024/11/19-webrtc-minutes.html#561c) was to
standardize what libwebrtc does when stereo is enabled, and this is
what it does.

Note: We still fail the test today though because "stereo opus" has not
been enabled-by-default. When it is the expectation is that we pass
both of these tests.

Bug: webrtc:379996136
Change-Id: Ibd6ee91a59d7c673bf53ad2302ba33f16b8b4ede
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6049355
Reviewed-by: Harald Alvestrand <[email protected]>
Commit-Queue: Henrik Boström <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1388674}

webrtc/RTCRtpEncodingParameters-codec-opus-stereo.https.html

@@ -69,9 +69,11 @@
   const audio = document.createElement('audio');
   audio.srcObject = new MediaStream();
   audio.srcObject.addTrack(remoteTrack);
-  assert_equals(await pollChannelCount(t, remoteTrack), 1,
-                'Remote track is also mono');
-}, 'Sending and receiving a mono track with opus');
+  // The stereo opus decoder outputs stereo regardless of the signal on the
+  // wire.
+  assert_equals(await pollChannelCount(t, remoteTrack), 2,
+                'Remote track is stereo (despite local track being mono)');
+}, 'Sending and receiving a mono track with opus (stereo decoder upmix)');
 
 promise_test(async t => {
   const pc1 = new RTCPeerConnection();