WebRTC Backend for real this time

[ValorZard]

fixes #2
This is going to take a bit, but now that we know this can work, let's full send it

[ValorZard]

Okay so two things:

1. the mock backend test thing needs to be using a mock Transport instead of a mock udp connection like its currently doing.
2. spectator needs to no longer be hardcoded to be using the UDP stuff
3. we still need to refactor out how connections work, right now we are making it so that the webrtc backend is "pretending" that it knows about the other peers addresses. This isn't the case, just give it the other players player id as assigned to them from the lobby.

[ValorZard]

Also we need to rename UdpProtocol to just Protocol, and move all of the UDP stuff to transport/udp instead.

(For example, I'm pretty sure webrtc datachannels already calculate the RTT for us instead of us having to come up with that calculation ourselves)

Edit: Okay so we still need to calculate the RTT ourselves, but we can still get some of the other stats from webrtc like the bytes sent and bytes received instead of calculating that ourselves:
https://developer.mozilla.org/en-US/docs/Web/API/RTCDataChannelStats

[ValorZard]

Also, another thing we can do once we're near the end of this PR is to add an HTML page just to check that all of the webrtc stuff can work on the browser, since that's lowkey the point of all of this.

An easy way to test it would be to compile the game on the web, and then maybe the host can just have a preset lobby id that it creates the lobby with (with some endpoint like /lobby/create_with_id/), and all other players join the lobby with that id, so we can then do the webrtc ggpo test in the browser

[ValorZard]

Okay I'm ready for other people to test this code.
If needed, I can host the signaling server on a cloud machine somewhere for people to connect to and test under real-ish network conditions.

[K4thos]

Went through the whole diff. The transport abstraction and unordered data channels sound good for ggpo. Looks like everything from your task list is already on the branch. The API polish is cosmetic, so fine as a follow-up rather than a blocker.

Main thing left is just getting it actually tested - happy if you set up a test signaling server and check if it works / invite others from Discord to try it with instructions. Once proved functional, I can handle the permanent host on AWS.

Engine side there's not much we need to adapt - just updating the netplay session setup in rollback.go to the new transport-based API. We can handle it for the 1.1 release. The change could land on the develop branch (used for our nightlies) once we branch off the 1.0 release at the planned feature freeze, and after your setup passes initial tests. If you like we can first prepare a standalone temporary release out of feature branch with the rollback.go adopted to the new API for this test.

[ValorZard]

@K4thos sounds good, I can do spin up a signaling server for testing so we can check if the WebRTC stuff works in different network conditions/peoples computers.

since the wasm build might be annoying to fully figure out, I think it’s fine to just focus on testing it out as just a native backend replacement for UDP since that already gives people NAT holepunching, which means no more VPN.

depending on what NATs some people computers are behind we might need a TURN server? Not sure, we will have to test.

[ValorZard]

Also yeah, I would want a test release of ikemen to check if this all works

[ValorZard]

@K4thos Check the updated README, there is now a way to distribute the test game as a server complete with signaling server.

just run ./scripts/package.sh

[ValorZard]

Known bug: for some reason, it takes like a second of lag on the host end (or maybe its firefox), before the host syncs up. But after that, its smooth sailing

[ValorZard]

I think so many of this changes are so big, we might as well make a /v2 and put this all under there.

(the pion does this with major breaking changes, they’re on /v4 now)

[ValorZard]

If we do do a breaking v2 change, I’d recommend getting rid of the UDP backend entirely. A lot of stuff GGPO implements on top of UDP, WebRTC just gives to us for free

[ValorZard]

TODO: Add an full explanation of what WebRTC is and why it's useful. I keep forgetting not everyone knows what I'm talking about.