get-relay-info tells providers where to bind for the relay

[ndeloof]

What this PR does, in one sentence

A provider running its service locally can now ask Compose where to bind its published endpoint (get-relay-info), so the relay reaches it on every platform without exposing the port on the LAN.

Closes #14257

Context

When a provider publishes an endpoint, Compose deploys a relay so dependents reach the service at its compose-native address. But the provider has to pick the address its endpoint binds, and on a standalone Linux engine no address is both relay-reachable and off the LAN: host.docker.internal resolves there to the bridge gateway, which a loopback-only listener cannot accept, while the wildcard exposes the port on every host interface. The bundled example provider works around it by binding 0.0.0.0 — trading LAN exposure for reachability — and a provider choosing loopback instead is silently limited to Docker Desktop.

What the PR brings

The approach retained: Compose owns the platform knowledge, the provider just binds what is announced. A new get-relay-info message answers with the networks the relay would join — the dependents' networks, exactly as selected for the relay deployment — each carrying the address a locally-run endpoint should bind to be reachable from the relay:

• on a standalone engine, the network's engine-assigned gateway — an address the provider's host owns on that bridge, reachable from the relay (and local containers) but not from the LAN;
• under Docker Desktop (detected through the engine label), 127.0.0.1 — the networks live inside the VM there, and the host's own loopback is, factually, where a host process is reached through the Desktop proxy.

Guardrails that bound the change:

• opt-in by construction: the message is provider-initiated, and only meaningful for the subset of providers running their service locally — a provider backing the service with a remote resource (e.g. a managed database) never sends it, and pays nothing (Desktop detection and network inspects run only on request);
• best-effort contract: a network whose address cannot be resolved is listed with the gateway field omitted — the provider falls back to a bind of its choice;
• unknown messages stay fatal by design — a provider requiring an unsupported message must fail loudly — so Compose now announces the message types it accepts in the COMPOSE_PROVIDER_MESSAGES environment variable of the provider process, letting providers adapt instead;
• inert for everything shipped: no existing message or relay behavior changes; the relay already passes routable upstreams verbatim and translates loopback ones, so announced addresses flow through the existing paths.

The example provider demonstrates the pattern — bind the first announced gateway, wildcard only when none is announced — which also closes the coverage gap noted in #14257: TestProviderPublishEndpoint now exercises the gateway path on Linux CI and the loopback path on Docker Desktop, instead of only ever testing a wildcard bind.

[docker-agent]

Assessment: 🔴 CRITICAL

One high-severity data race confirmed in the new GetRelayInfoType handler.

[codecov]

Codecov Report

❌ Patch coverage is 75.71429% with 17 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
pkg/compose/plugins.go	66.66%	11 Missing and 6 partials ⚠️

📢 Thoughts on this report? Let us know!

[docker-agent]

Assessment: 🟢 APPROVE

[glours]

TestExecutePlugin_GetRelayInfo and TestExecutePlugin_GetRelayInfoDesktop cover the happy path and the Desktop path, but nothing exercises relayInfo's "gateway unresolved" branch (NetworkInspect error, or an IPAM config with no valid IPv4 gateway) — the exact case the omitempty/best-effort contract in relay.go is built around. Can you add a case mocking NetworkInspect to fail (see notFoundError in executor_test.go, already used this way in observed_state_test.go:387) and asserting the network is still listed with Gateway empty? Without it, a later change to the err == nil/cfg.Gateway.IsValid() guards could start sending a wrong non-empty gateway with nothing catching it.

[ndeloof]

@glours added in 162ebb8: TestExecutePlugin_GetRelayInfoUnresolvedGateway covers relayInfo's "gateway unresolved" branch with three subtests — NetworkInspect failing, an IPv6-only gateway, and no gateway entry at all — each asserting the network is still listed with Gateway left empty.

[docker-agent]

This review covers only the commits pushed since 9badbe3.

Assessment: 🟢 APPROVE

The single change in this incremental diff — the new TestExecutePlugin_GetRelayInfoUnresolvedGateway table-driven test — is well-constructed. It correctly covers all three best-effort contract branches for unresolved gateways: a failing NetworkInspect, an IPv6-only IPAM gateway, and an absent IPAM gateway. Mock expectations, variable-name assertions (RELAY_NETWORK / RELAY_GATEWAY), the len(variables.prefixed) == 2 invariant, and the subprocess helper pattern all match the production code. No bugs found in the diff.

[docker-agent]

Assessment: 🟢 APPROVE

[docker-agent]

This review covers only the commits pushed since 162ebb8.

Assessment: 🟢 APPROVE

The single change in this incremental diff — closing the stdout pipe's read-end when ReadString fails in serveDemo — is correct and introduces no new issues.

stdout is an io.ReadCloser returned by server.StdoutPipe(). Because Wait() is intentionally never called (the subprocess outlives the function), nothing else would release the pipe's read-end file descriptor on the error path. The explicit _ = stdout.Close() cleanly plugs that leak, mirroring the identical pattern already present on the server.Start() failure path. Discarding the Close() error is appropriate since the function is already returning a more meaningful error from ReadString, and there is no double-close risk.

[glours]

LGTM