Swap to APIServer for all communications

[dcantah]

Today, we have a sort of odd model all things considered. We talk to the APIServer to do the initial container creation, which mostly all of the work is just registering the runtime helper with launchd. After this registration, almost all communication from a client is talking directly to that runtime helper. This has a couple rather annoying issues in that we now need a sort of event/notification channel that the helper will establish with the APIServer for errors/start/exited cases.

If instead of talking to the runtime helper directly, we instead took a detour through the APIServer, the APIServer is clued into exactly what order of operations is occurring. This makes "did starting the container fail? Okay we should clean up" scenarios much simpler, and it also simplifies the clients quite a bit as they don't need this split brained client model, everyone just talks to the APIServer. This change is in pursuit of that. I have reworked our clients, the ContainerService and some of our XPC types to accomplish it.

The biggest "contract" change is in the SandboxService. Today we have on the flag when we register any runtime helper that makes any xpc messages wake up the registered process. This isn't great in scenarios where the process have may crashed, or it exited normally and we're just trying to invoke an RPC on it. Today the helper would spawn again and try and answer our request. It'd be much nicer if we have a connection object that will become invalid if the process that vended it to us is gone. To accomplish this, now the runtime helpers will listen on an anonymous xpc connection and vend endpoints from this via only one handler exposed by the SandboxService (createEndpoint). From that point onwards all communication will be through the endpoint the service vended a client.

Pushed the wrong button

[jglogan]

Note about code not modified in this PR:

private nonisolated func configureProcessConfig()

This should be able to become:

private static func configureProcessConfig()

Same for closeHandle().

[jglogan]

Another lowkey obsessive nit in the non-modified code above - move getDefaultNameserver out from between the configure...() funcs. All the private methods could probably stand to be reordered sensibly. In a swift file that's pushing 1200 lines it will help new developers.

[Mcrich23]

Hey! So sorry, but in an effort to make plugin development more possible #603 and #635 have lead to the CLI folder being renamed to ContainerCommands and that will impact the merging of your pull request. Just an FYI, so you understand the issue when you are resolving conflicts.

[dcantah]

Converting to draft because there's a small cz change that I want in that will allow us to "fix" some behavior in stop()

[dkovba]

👍

[dkovba]

This code repeats 4 times. Consider extracting it into helper methods in XPCMessage:

 static func stdioKey(for index: Int) throws -> XPCKeys {
      switch index {
      case 0: return .stdin
      case 1: return .stdout
      case 2: return .stderr
      default:
          throw ContainerizationError(.invalidArgument, message: "invalid fd \(index)")
      }
  }

 static func setStdioHandles(on request: XPCMessage, stdio: 
  [FileHandle?]) throws {
      for (index, handle) in stdio.enumerated() {
          if let handle {
              request.set(key: stdioKey(for: index), value: handle)
          }
      }
  }

[dcantah]

John had commented the same, I'm going to do that (and some other cleanups) in a followup

[adityaramani]

Changes look good!