chore: add network extension manager

[ethanndickson]

Relates to #2.

Adds the Manager abstraction that:

• Downloads the dylib
• Calls the SignatureValidator on a downloaded dylib
• Passes network settings to NEPacketTunnelProvider
• Owns the TunnelHandle
• Reads and writes to the Speaker

Eventually, it'll act as the middleman between the tunnel Speaker and the XPC speaker.

[ethanndickson]

• chore: extract CoderSDK to framework #19
• chore: add network extension manager #18 👈 (View in Graphite)
• chore: add dylib downloader and validator #16
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[ethanndickson]

I don't think this is worth unit testing, at least right now. We'd need to mock the PTP, the TunnelHandle, the validator, and eventually the XPC speaker, all for a relatively simple abstraction that's mostly error handling.

[ethanndickson]

This is a little frustrating - theTask type itself is generic on two type parameters, Success and Failure, but the only APIs you can await on a task are either value with an untyped throws or result which returns a type-erased any Error error variant. It's very similar for continuations, the type itself is generic but there's no way to return that typed error.

As an aside, I think I'm becoming more of a fan, for binaries at least, of just having a single opaque error type, propagating it with context, and then just displaying it, ala Go or Rust's anyhow - it's so rare that one or more of the error variants are recoverable, and that the caller needs to know which one.

[ethanndickson]

@coadler Requesting your review here since Spike is OOO, and this is pretty relevant to you. This is the portion of the network extension that communicates over XPC.

[ethanndickson]

Merge activity

• Jan 14, 12:19 AM EST: A user started a stack merge that includes this pull request via Graphite.
• Jan 14, 12:19 AM EST: A user merged this pull request with Graphite.