* Two users can activate their cameras locally and then connect them together
with WebRTC with video and audio support working!
* Limitation: users need to be broadcasting video themselves before they can
connect to someone's camera. If the offerer doesn't add tracks of their own,
the SDP offer doesn't request video channels; so even though the answerer
adds their tracks to the connection, they aren't used by the offerer.
* As currently implemented, the offerer's camera feed will also appear on
screen for the answerer - every video connection opens the feed both ways.
Compared to the previous commit (where clients shared SDP messages but not
ICE candidates or anything further) the fixes and learnings were:
* The back-end was trying to relay candidate messages, but there was a JSON
marshalling error (json object casted into a string) - changed the Message
type to map[string]interface{} and both sides could exchange ICE candidates.
* Both sides needed to add their video tracks to the connection so that there
was anything of value to be sent over the WebRTC channel.
Other changes:
* Server will send a ping message every minute to connected WebSockets.
* WebRTC pees exchange local/remote descriptions ("offer" and "answer")
* They don't seem to exchange ICE candidates yet
* Some back and forth happens but the final WebRTC stream connection
isn't established yet.
* Reworked full screen CSS layout for the chat.html, still using Bulma
components with some custom CSS Grid.
* Duplicate username handling: server can push a new username to change
the client's selection.
* Who List sync between clients.
* Local video casting works so far - plays back your camera in the local
feed. Your video broadcasting boolean is synced to backend, which
lights up the video button in the Who List.
