chore: run coder connect networking from launchdaemon

[ethanndickson]

Continues to address #201.

This PR reworks all XPC connections, such that the networking code runs within the privileged helper, instead of the network extension.

The XPC interfaces are described in XPC.swift, and roughly follow this sequence diagram:
(One difference is that we don't posix spawn the tunnel in this PR)

sequenceDiagram
    note left of App: User requests to start VPN:
    App->>+NetExt: Start VPN
    NetExt->>+PrivHelper: Request start VPN with TUN FD
    note right of PrivHelper: Privileged helper downloads and verifies binary.
    PrivHelper->>Tunnel: posix_spawn child process with FDs
    PrivHelper->>+Tunnel: Send proto start request
    Tunnel-->>-PrivHelper: Send proto start response
    PrivHelper->>+NetExt: Request for network config change
    NetExt-->>-PrivHelper: Response for network config change
    PrivHelper-->>-NetExt: Start VPN respons
    NetExt-->>-App: VPN started
    App->>PrivHelper: Request peer state
    PrivHelper->>Tunnel: Request peer state
    Tunnel-->>PrivHelper: Peer state response
    PrivHelper-->>App: Peer state response

    note left of App: Tunnel updates (bypass NetExt):
    Tunnel->>PrivHelper: Tunnel update proto message
    PrivHelper->>App: Tunnel update proto message

    note left of App: User requests to stop VPN:
    App->>+NetExt: Stop VPN
    NetExt->>+PrivHelper: Request stop VPN
    PrivHelper->>+Tunnel: Request stop VPN
    Tunnel-->>-PrivHelper: Stop VPN response
    note right of Tunnel: Tunnel binary exits
    PrivHelper-->>-NetExt: Stop VPN response
    NetExt-->>-App: VPN stopped

Loading

Of note is that the network extension starts and stops the daemon running within the privileged helper.
This is to support starting and stopping the VPN from the toggle in System Settings, and to ensure the "Connecting" and "Disconnecting" phase of the system VPN is indicative of the time the VPN is actually setting itself up and tearing itself down.

To accomplish this, the privileged helper listens on two different service names. One is connected to by the app, the other the network extension. (Once an XPC listener is connected to, communication is bidirectional)

[ethanndickson]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• fix: add code signing requirements to xpc connections #206 : 2 dependent PRs (#209 , #210 )
• chore: run coder connect networking from launchdaemon #203 👈 (View in Graphite)
• chore: make helper launchdaemon approval mandatory #205
• main

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

[ethanndickson]

Important to note that I've refactored all the XPC connections to use this pattern. With this, you're guaranteed that either the the XPC reply will be run (proxy.ping { reply } in this case) or the [...]WithErrorHandler callback.

[ethanndickson]

Temporary. I've put it in /var/root/Library/Application\ Support/com.coder.Coder-Desktop/ as part of the PR that downloads the slim binary.

[deansheather]

The XPC code seems a lot nicer but the type names and directions of the XPC types are hard to understand

[ethanndickson]

The class is called HelperXPCClient, but you can't have multiple Swift files with the same name. So, I've prepended NE, since this is the HelperXPCClient that runs within the network extension.