Closescoder/internal#381.

• Moves the VPN-specific app files into aVPN folder.
• Adds an emptyResources folder whose contents are copied into the bundle at build time.
• Adds aMutagenDaemon abstraction for managing the mutagen daemon lifecycle, this class:
  • Starts the mutagen daemon usingmutagen daemon run, with aMUTAGEN_DATA_DIRECTORY inApplication Support/Coder Desktop/Mutagen, to avoid collisions with a system mutagen using~/.mutagen.
  • Maintains agRPC connection to the daemon socket.
  • Stops the mutagen daemon overgRPC
  • Relays stdout & stderr from the daemon, and watches if the process exits unexpectedly.
  • Handles replacing an orphanedmutagen daemon run process if one exists.

This PR does not embed the mutagen binaries within the bundle, it just handles the case where they're present.

Why is the file sync code in VPNLib?

When I had the FileSync code (namely protobuf definitions) in either:

• The app target
• A newFSLib framework target

Either the network extension crashed (in the first case) or the app crashed (in the second case) on launch.
The crash was super obtuse:

Library not loaded: @rpath/SwiftProtobuf.framework/Versions/A/SwiftProtobuf

especially consideringSwiftProtobuf doesn't have a stable ABI and shouldn't be compiled as a framework.

At least one other person has ran into this issue when importingSwiftProtobuf multiple times:
apple/swift-protobuf#1506 (comment)

Curiously, this also wasn't happening on local development builds (building and running via the XCode GUI), only when exporting via our build script.

Solution

We're just going to overloadVPNLib as the source of all our SwiftProtobuf & GRPC code. Since it's pretty big, and we don't want to embed it twice, we'll embed it once within the System Extension, and then have the app look for it in that bundle, seeLD_RUNPATH_SEARCH_PATHS. It's not exactly ideal, but I don't think it's worth going to war with XCode over.

TODO

• Replace theProcess withhttps://github.com/jamf/Subprocess