feat: add data channel to report muted state

[WofWca]

This addressed the "remote video" part of #62.

TODO:

• Actually use it.
  There is a blocker, see
  feat: try to show avatar if remote has no video #81

I have tested this with a Desktop <-> Desktop call, and the remote's avatar is correctly shown when they enable / disable video, even if they disabled it before the call has started.

This change is backwards-compatible, i.e. the remote does not have to support this data channel and report its muted state - it's optional.

[WofWca]

@Amzd I suggest this protocol for communicating the muted state in a way other than replaceTrack(null) (which is not reliable).

[Amzd]

This can work for iOS. Should be fine. Can you add more detail on why replaceTrack doesn't work? That api would still be preferred even with the datachannel since otherwise the webapp keeps sending black frames(wasting bandwidth), right?

[WofWca]

That api would still be preferred even with the datachannel since otherwise the webapp keeps sending black frames(wasting bandwidth), right?

Yes, if replaceTrack worked properly (or at least as we expect it), we wouldn't need a data channel.

Can you add more detail on why replaceTrack doesn't work?

I think you mentioned that it's not nice that the last frame is being shown for a second or two after you disable the video.
Additionally, the muted state is apparently not always received by the remote.

I will add comments in the code.

[Amzd]

Okay so replaceTrack issues:

• last frame remains on screen when turned off (because it stops sending black frames)
• the muted state is not always received by the remote

Both of these issues are fixed by the datachannel of this PR, and replaceTrack(null) still brings the advantage of saving the bandwidth of the black frames so I think it would be nice to have both the datachannel and the replaceTrack.

[WofWca]

Umm we just tested the track.muted state again on 481f543, and the muted state is not in fact received by the callee when the caller is iOS. Video was disabled initially. Then the caller enabled and disabled the video, and track.muted remained to be false. Tested with document.querySelector('video').srcObject.getTracks().map(t => [t.kind, t.muted]). IDK if it's the changes that we did to calls-webapp after this comment was made #79 (comment) or the Chromium's inner randomness.
Anyways, this MR should cover this issue.

[WofWca]

We have tested this MR with the iOS implementation. Works.