Reuse XPC connections across container operations

[realrajaryan]

• Closes [Request]: ClientContainer should not create a new xpc connection per request #666.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update

Motivation and Context

Currently, ClientContainer is overloaded, it's used for both data (during list(), you get given a ClientContainer) and to talk to the daemon. Each container operation creates a new XPC connection, which is pretty wasteful e.g. container stop --all with 10 containers creates 11 XPC connections (1 for list and 10 for individual stops)

To address this list(), get(), and create() will now return ContainerSnapshot instead of ClientContainer, and ClientContainer now accepts an optional XPCClient parameter for connection reuse so multiple operations can share the same connection. Commands that perform bulk operations now create a single shared XPCClient and pass it to all ClientContainer instances

Testing

• Tested locally
• Added/updated tests
• Added/updated docs

[jglogan]

Having the caller provide a snapshot to a public method feels a little strange. I'd expect them to be able to create a ClientContainer using just a container ID.

Since we're now using snapshot as the return type for everything, do we really need to store configuration, status, and networks between calls?