Fix the VPN locking up when smoltcp breaks

• After some fun hours debugging, I noticed that smoltcp seems to get into a state where it issues a poll_delay of zero (meaning poll again immediately), and keeps doing that forever, even if you do poll it.
• This would lock up the VPN entirely and stop packets flowing, because of a subtlety in how tokio::select! works: it won't poll later futures if earlier futures return immediately.
  • Although, even with the futures in the correct order, it's still possible to starve the device, or at least spin forever in a way that's unpleasant...
• To fix this, we do two things: ignoring poll delays of zero, and reordering the futures properly.
• The bug still exists and will still cause degraded / stupid performance when it gets hit, so we'll need to investigate it. However, this at least contains it for a while.
  • It only triggers per-socket (for example, loading up fast.com seems to reasonably reliably reproduce it for me when the streams get over >15 Mbps), so when the affected sockets close, things go back to normal.