sd and sdgram networks for systemd.socket named file descriptors

[MayCXC]

Assistance Disclosure

No AI was used.

Implements #7243 with https://github.com/MayCXC/caddy-systemd-socket-activation to read LISTEN_FDS and LISTEN_PID from the environment as well, support binding port ranges to homonymous file descriptors, and reserve the datagram networks for h3.

Caddyfile syntax comparison:

• bind fdname/name:10 -> bind sd/name/10
• bind fdgramname/name:10 -> bind sdgram/name/10

Support for both is moved to the linux && !nosystemd target, and custom network support code is isolated in networks.go. This is also a nice way to implement iface custom networks for #7256

[francislavoie]

FYI @Siomachkin

[francislavoie]

Moving this will be a breaking change to https://sourcegraph.com/github.com/tailscale/caddy-tailscale/-/blob/module.go?L36-39

[francislavoie]

Can we leave this in and have this call caddy.RegisterNetworkHTTP3 to keep backwards compat for a while, and mark this as deprecated?

[MayCXC]

oh yeah that works, I'll put it back.

[MayCXC]

drafted to evaluate a bind fd/{systemd.socket.name} placeholder as well as bind {iface.eth0}.

[francislavoie]

How does the nosystemd build target work? That doesn't seem like a Go built-in, so it would mean -tags nosystemd would need to be used, right?

I don't see a problem with leaving that code compiled in for all linux builds because it requires a pretty specific combination of env vars to be set to work anyway, and throws an error that the user needs to handle otherwise.

[MayCXC]

How does the nosystemd build target work? That doesn't seem like a Go built-in, so it would mean -tags nosystemd would need to be used, right?

I don't see a problem with leaving that code compiled in for all linux builds because it requires a pretty specific combination of env vars to be set to work anyway, and throws an error that the user needs to handle otherwise.

yes, it is a tag. the best reason I can give for the target is that it smells to test this feature on osx and windows. using a negated target leaves it on by default.

that said, closed in favor of #7340

[francislavoie]

Well the linux target is enough to avoid osx/windows, no need to an extra build flag IMO