windows: use non-blocking mode for wintun

[ReactorScram]

making an issue so I remember

https://github.com/firezone/firezone/blob/windows-headless-client/rust/connlib/tunnel/src/device_channel/tun/tun_windows.rs#L60-L108

[ReactorScram]

In-progress on the invalidate-dns branch

[ReactorScram]

This was working in commit e18fbf635 locally but I want to see if #2975 gets resolved first, just to be safe.

[ReactorScram]

I get about 33/10 down/up Mbps with the worker thread and blocking mode, so it's not the end of the world for performance. My Internet is supposed to be like 88/10 without the tunnel.

[ReactorScram]

I read a little of the RegisterWaitForSingleObject docs. Monday I need to:

• Make sure I'm calling Unregister at the top of poll_recv
• Pass the "execute only once" flag cause I think right now it's blowing up and recursively re-registering itself on every poll_read (Alternately, just only register once? That would save some Arc cloning. I'd need to be sure it calls the callback after the timeout lapses, though. I think the docs have a copy-paste typo regarding whether it calls the callback after a timeout.)
• Set a timeout like 30 seconds or 60 seconds so that if I can't unregister and shut it down for some reason, it'll still unregister the callback and not leak

Also the docs and SO indicate that RegisterWaitForSingleObject just uses a thread pool internally with threads that block waiting on objects. It might be better than using our own worker thread or using spawn_blocking, since other Windows stuff in our process maybe ends up sharing a wait thread somehow, but it's opaque. I could do a worker thread (since this is long-running, I think spawn_blocking wouldn't be right) with a timeout and a shutdown signal, basically how wintun's blocking recv does it, but idk.

There are many ways it could be done, none are great. After thinking about all this, I do want to ditch the worker thread, since wintun (the crate) internally does an infinite block on WaitForMultipleObjects, and I'd feel safer with a timeout there.

[ReactorScram]

I ended up taking a different approach, also removed the Arc, see PR

[ReactorScram]

Moving back to Todo, haven't worked on this for a few days and honestly I'd rather keep the blocking impl for a little longer

[ReactorScram]

Stopping this for now, we can come back to it at any time