Fix regression in wasm connections behind NATs

[johanhelsing]

Something in #54 broke connections between me and another peer (both of us behind NATs)

In this PR, we start sending null ice candidates, and add them on the receiving end. I'm not completely sure what the point of it is, but MDN examples do this so it's probably best if we do it too.

Sadly, this alone wasn't enough to fix the regression. Adding back the wait for ice gathering to complete, however, did fix the issue. So that means that on wasm, we now have some weird frankenstein of ice-trickle and non-trickle, but the regression is gone, and cross-play still seems to work. So it's still better than before, and I'm really anxious to get a fix for the regression merged, even if it's ugly and I don't really understand how it fixes it.

If anyone has ideas about what could be wrong with the trickle implementation, please let me know.

Fixes: #58

@rozgo

[rozgo]

This WebRTC business is so brittle. How unfortunate that this broke NAT. I'm catching up with all the changes and testing on this side. Thanks for looking into this.

EDIT: Works on our apps.

[johanhelsing]

Thanks for confirming. I think it's just the wait (357144f) that makes the difference. I found a way to more reliably test the regression without asking someone else to help me test. Here's how I do it:

1. My regular dev machine behind a regular ipv4 nat.
2. My laptop connected to tethering on my phone. (note, just connecting with the phone itself is not enough, but using tethering is)