refactor(connlib): don't re-implement waker for TUN thread

[thomaseizinger]

Within connlib - on UNIX platforms - we have dedicated threads that read from and write to the TUN device. These threads are connected with connlib's main thread via bounded channels: one in each direction. When these channels are full, connlib's main thread will suspend and not read any network packets from the sockets in order to maintain back-pressure. Reading more packets from the socket would mean most likely sending more packets out the TUN device.

When debugging #7763, it became apparent that something must be wrong with these threads and that somehow, we either consider them as full or aren't emptying them and as a result, we don't read any network packets from our sockets.

To maintain back-pressure here, we currently use our own AtomicWaker construct that is shared with the TUN thread(s). This is unnecessary. We can also directly convert the flume::Sender into a flume::async::SendSink and therefore directly access a poll interface.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
firezone	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 29, 2025 1:10pm

[jamilbk]

Anything to remove complexity LGTM. I think the hunch about not reading network packets because we can't write to the TUN device makes sense.

I guess the key question is why can't we write to the TUN device. If it's due to an OS error or something outside of our control, I guess we'd have to consider adding logic that detects a "stuck" channel and rolls over the file descriptor?

That wouldn't be an option on Apple though...