core: addresses.go funcs renames

[MayCXC]

HEAD removes the unreleased ParseNetworkAddressFromHostPort that I added in #6573. I would also like to rename na.JoinHostPort to na.JoinAt, to make it clear that it does not take the same parameters as net.JoinHostPort. finally, I would like to change the signature

func getListenerFromPlugin(ctx context.Context, network, addr string, config net.ListenConfig) (any, error)

to

func getListenerFromPlugin(ctx context.Context, network, host, portRange string, portOffset uint, config net.ListenConfig) (any, error)

so that plugins are aware of the port range and offset of their network addresses.

Together, these changes are meant to make a clearer interface for plugins to choose either ParseNetworkAddress(JoinNetworkAddress(...)).Listen or net.Listen(ParseNetworkAddress(JoinNetworkAddress(...)).JoinAt(portOffset)) to create their listeners, with preference for the former so they are added to the listener pool. The offset parameter in getListenerFromPlugin also lets https://github.com/MayCXC/caddy-systemd-socket-activation?tab=readme-ov-file use its custom networks to listen to a port range with a systemd named socket unit, which is a very clean integration.

[MayCXC]

the last commit widens some test cases for SplitNetworkAddress, meaning no incompatibilities with previous versions, but it is new behavior. I think it is a sensible change; caddy already considers the port and the network optional for the argument to SplitNetworkAddress, because they are optional in the config. so now the host is optional, as it is also optional in the config. the result is that network, host, and port can all be returned empty without an err from SplitNetworkAddress, which is what I would expect when parsing the configuration.

so all that is left to put custom network plugins where I want them to be is na.JoinHostPort -> na.JoinAt, and the new getListenerFromPlugin parameters.

[MayCXC]

it might also be better to return an error if network, host, and port are all "". but I do think any two of the three should be allowed to be blank.

[francislavoie]

You don't need to keep clicking merge btw, we can do that after reviewed and about to be merged.

This looks like a good simplification to me. But I'll let @mholt take a look first.

[MayCXC]

You don't need to keep clicking merge btw, we can do that after reviewed and about to be merged.

This looks like a good simplification to me. But I'll let @mholt take a look first.

I do that to check if conflicts need to be resolved ahead of time. This PR is also just half the change, to check if changing split is viable.

[mholt]

Thanks for the simplification / consistency enhancements!