Auto-detection of server and client types for most common cases

[jakaplan]

This introduces full auto-detection for common server types. For clients, specifying the name of the service will still be needed, but the caller won't in most cases need to know whether they're calling an XPC service or an XPC Mach service.

[jakaplan]

So far only the server portion of this has been implemented. The client section is still functional as-is, but it'd be quite confusing to use (and much of the documentation no longer makes sense). An update to this PR will be forthcoming that adds the client portion.

[jakaplan]

@amomchilov available for you to review if you'd like to do so

[amomchilov]

Hey Josh, I'd love to review, but I'm currently sick. Don't wait on me, but I'll provide feedback to merge in later, if any

[jakaplan]

Oh no, hope you start feeling better soon!

[amomchilov]

It took a few days, but I am! Covid sucks.

This PR has quite a bit going on, and I'm having troubling understanding the changes. Could you provide me some more context?

[jakaplan]

It took a few days, but I am! Covid sucks.

Yeah it really does. I had it a couple months ago, it was no fun at all.

This PR has quite a bit going on, and I'm having troubling understanding the changes. Could you provide me some more context?

Sorry, in retrospect I could've split this up into a few different PRs. There are three main pieces here:

• Auto-detection for XPCClient
  • This is pretty straightforward
  • Checks if a bundled XPC service has a bundle identifier matching the provided name, then creates a client accordingly
• Auto-detection for XPCServer
  • This is a bit more involved compared to the client
  • For each type of service that this framework has built-in support for, a check is done to see if the running process matches a "description" of what that ought to look like. This intentionally isn't the same as the criteria to actually create an XPCServer for it. For example to create a server for a blessed helper tool requires there to be exactly one MachService entry, but this isn't relevant in determining whether the running process is a blessed helper tool.
  • The intention as follow up PRs is to add at least two more types which are autodetected, the newly added "daemon" and "agent" that can be registered by SMAppService as of macOS 13.
• Moving endpoint from NonBlockingXPCServer to XPCServer and adding endpoint to XPCServiceServer
  • Because server retrieval is now all through one function call (except for anonymous servers) it can only return XPCServer and not also NonBlockingXPCServer. This is fine for the start() call because that functionality really is only useful for an anonymous server as far as I can tell. However, endpoint was also part of that protocol and that's problematic.
  • endpoint was moved to XPCServer. I could have add it return an optional and if the server was an XPCServiceServer it'd always return nil, but I prefer this approach where all servers can always return an endpoint - it just requires some more complexity under the hood.
  • The way this is accomplished is if an endpoint is accessed for an XPCServiceServer it creates an anonymous listener connection and then treats those incoming connections the same as those coming from xpc_main(...) - it's transparent to users of XPCServer. In the common case where endpoint is never accessed, the anonymous listener connection is never created.

[jakaplan]

@amomchilov I've made changes based on your feedback and added all the parts to this PR (sorry there are so many, will aim for smaller PRs in the future) that I had envisioned

[jakaplan]

I'm going to go ahead and merge this, but happy to receive further feedback on this PR