This also separates out concerns better - UI elements just need to poke
getCallForRoom rather than care if the thing they are displaying is a
true 1:1 for this room ID or actually a conf room.
Previously, the CallView was attached to the RoomView, so you would get
a new CallView each time you changed the room and the one you changed
from would be destroyed. This would destroy media capture/playback as
the element was no longer in the DOM.
This is now fixed by having a "global" CallView which is attached at
the MatrixChat "page" level in the DOM hierarchy. This CallView isn't
scoped to a particular room; it will render any "active" call it can
find that *isn't the current room being displayed*. This has the side
effect of enforcing 1 call per app semantics as only the first active
call found is returned.
This fixes https://github.com/vector-im/vector-web/issues/31
This is unfinished (CSS for the global call view isn't done)
This has a number of failings currently: 1) It needs to hide the 1:1 conference
room, 2) Swapping tabs on the outbound call mutes audio (this just seems to be
a vector bug since I can repro this on a normal 1:1 voip call), 3) Needs a big
plinth/etc to say the conf call is in progress.
CallView is the container for either VideoViews or WaveformViews. All UI
elements listen for 'call_state' payloads and then call
CallHandler.getCall(roomId) to extract the current MatrixCall for that room.
We can't do this via stateful dispatches because dispatching does not preserve
ordering empirically (probably due to setTimeout).
