connlib: re-design API between clients & tunnel

[thomaseizinger]

This is a tracking issue that is meant to capture some ideas for re-designing how we communicate from the Tunnel with the individual clients. Currently, this done via callbacks in two places:

1. From within the Tunnel to the various "glue" crates for the clients
2. Across the FFI boundary (only Android and Apple)

Tasks

Beta Give feedback

1. Remove (1) in favor of events being emitted from Tunnel and sent into a channel in the Eventloop
2. connlib: move client-specific TUN code to clients #4473
   area/connlib kind/refactor +2

The goal is to free connlib from as much platform-specific code as possible. This allows Tun to be a Sink + Stream of IpPackets and all the platform-specific stuff is in the already platform-specific client crates.

Emitting a stream of events changes from a push to a pull design, giving clients more flexibility in handling them by e.g. having access to &mut self, async etc.

We might be able to remove the callbacks across the FFI boundary with a move to UniFFI (#3959) which supports async functions. That would allow Android as well as Swift to use their native co-routine / tasks mechanism to directly respond to the next emitted event and handle it accordingly.

[thomaseizinger]

Closing because it duplicates what is now in other issues.