service: support multiple sockets in DSL

[apainintheneck]

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes? Here's an example.
• Have you successfully run brew style with your changes locally?
• Have you successfully run brew typecheck with your changes locally?
• Have you successfully run brew tests with your changes locally?

---

Closes #15945

This adds support for multiple named sockets to the service DSL. It also retains backwards compatibility with the previous DSL where you can declare one socket. The only change is that the default socket name is now listeners instead of Listeners to go along with lowercase Ruby symbol naming conventions.

CC: @SMillerDev

[MikeMcQuaid]

Great work so far @apainintheneck! Looks good to me with a slight (non-blocking) naming suggestion.

[MikeMcQuaid]

Suggested change

	sockets "Socket" => "tcp://0.0.0.0:80", "SocketTLS" => "tcp://0.0.0.0:443"
	sockets socket: "tcp://0.0.0.0:80", socket_tls: "tcp://0.0.0.0:443"

or something might be a nicer/more Ruby-like API. Not huge on the socket:/socket_tls: naming, though; would welcome better ones.

[apainintheneck]

I think using a string here gives users more flexibility when it comes to matching the exact names of the sockets they already use internally. Or at least that was my thinking.

[MikeMcQuaid]

I think using a string here gives users more flexibility when it comes to matching the exact names of the sockets they already use internally.

@apainintheneck Can you elaborate on this a bit? Do the names of these sockets matter and, if so, when/how are they used?

To be clear: this may be entirely just correctly my understanding 😁

[apainintheneck]

I didn't know what I was talking about 😄.

From the man page man launchd.plist:

Sockets <dictionary of dictionaries... OR dictionary of array of dictionaries...>

This optional key is used to specify launch on demand sockets that can be used to let launchd know when
to run the job. The job must check-in to get a copy of the file descriptors using the
launch_activate_socket(3) API.  The keys of the top level Sockets dictionary can be anything. These
keys are meant for the application developer to associate which socket descriptors correspond to which
application level protocols (e.g. http vs. ftp vs. DNS...).

Looking at it again we use symbols for rest of the service DSL. I'll change the code to use symbols.

[apainintheneck]

How worried should we be about validating socket names? They need to fit into the plist so I assume some names are off limits, right? Like for example names including < would break the XML.

[MikeMcQuaid]

How worried should we be about validating socket names? They need to fit into the plist so I assume some names are off limits, right? Like for example names including < would break the XML.

I feel like if we're writing the XML using a ReXML: this stuff will be handled for us.

[apainintheneck]

I feel like if we're writing the XML using a ReXML: this stuff will be handled for us.

Of course, brain fart.

[MikeMcQuaid]

Looks great! One more style thought but optional/not blocking merge.

[MikeMcQuaid]

Suggested change

	sockets socket: "tcp://0.0.0.0:80", socket_tls: "tcp://0.0.0.0:443"
	sockets http: "tcp://0.0.0.0:80", https: "tcp://0.0.0.0:443"

or something perhaps so these names are a bit more meaningful?

alternatively, if we want to just generate the names for people:

Suggested change

	sockets socket: "tcp://0.0.0.0:80", socket_tls: "tcp://0.0.0.0:443"
	sockets ["tcp://0.0.0.0:80", "tcp://0.0.0.0:443"]

[apainintheneck]

I'll update the names in the docs to be more meaningful like you mentioned. I think allowing names can be helpful for documentation reasons but I don't feel very strongly either way.

[MikeMcQuaid]

Looks great, thanks again @apainintheneck!