Add connlib basic implementation

[conectado]

Overview

This PRs establish a basis on which to build on for connlib, this doesn't try to be a working version of connlib.

This PR tries to:

• Establish a way to handle egress/ingress message
• Organize code in crates
• Have the most basic Tunnel showing how webrtc + wireguard works
• Establish how to handle errors
• Establish an initial FFI API

There's still a lot to do, there are quite a few "TODO"s in the code but here are some general things

• We assume here that the client will be running when on_error is called, so it can disconnect the Session, this will not always be the case and we need to disconnect the session from Rust.
• Use Phoenix channel's topics and events in a way that's compatible with the portal.
• Implement all missing functions for messages and wireguard stats.
• Fix integration with clients
• Unit and Integration tests

This changes are only tested to be compiled not to be working but creating the PR now so that we don't keep bloating the PR.

Crate structure

We have 2 big directories:

• libs: libraries that have buisness logic
• clients: are the outter shells that directly interact with outside code (or are directly a binary)
• gateway: Contains the actual gateway binary

These are self-explainatory save for directories in libs:

• common: have types shared by all connlib.
• tunnel: is the actual data-plane logic.
• client: buisness logic specific for clients.
• gateway: buisness logic specific for gateway.

Platform specific behavior

For now, only linux and macos have an implementation and we are directly using boringtun's device although moving to our own implementation won't be hard.

Next steps

My next step is making it actually work with the portal, for that I'll fix the gateway binary and make a simple headless client.
Once that is done we can start working on client-specific ffi and be sure that it is working.

[jamilbk]

Just did a quick first pass. Looking good, just want to drop a subtle reminder to follow boringtun's licensing requirements where appropriate before this gets merged / shipped.

[conectado]

Just did a quick first pass. Looking good, just want to drop a subtle reminder to follow boringtun's licensing requirements where appropriate before this gets merged / shipped.

Oh good catch 👍

[conectado]

@jamilbk could you double check if this copyright notice is enough?

[jamilbk]

adding @roop for visibility on the Apple FFI bridge

[jamilbk]

Thanks @francesca64 for the thorough review! In the main repo we use codespell + precommit to catch typos like these, noting here in case it's useful

[jamilbk]

Adding @timClicks for a review on organization/structure. @timClicks -- probably will need a call to provide more context around Connlib but it's meant to be our core networking library used across Apple/Android/Windows/Linux. This may be helpful as well:

• High-level software component diagram
• Epic tracking Connlib work

[roop]

Having connect return a Result<Self, SwiftConnlibError> is nice. Presumably, it would become func connect(portal_url: String, token: String) throws -> WrappedSession in Swift (it doesn't build currently, so I can't see the generated bridge code).

With this PR, how should the Swift code tell the Ruby code about the callback handlers to be called? (Previously, we passed in a CallbackHandler struct with functions.)

Apart from that, I think we should add the following callback handlers in the FFI:

• Log handler: When running connlib inside the network extension, stdout and stderr are not accessible, so we'll have to call the Apple logging functions to debug what happens in Rust code. So having a logging callback is important.
• Error handler: While it's good that connect can now return an error, we should probably have a callback to tell the client in case something went wrong in the connlib side while the tunnel was up. (Edit: I see it's already added as onError)