daemon: bound startup goroutine creation - #52709

Summary

Follow-up to #38301: make the existing startup semaphore bound goroutine creation as well as active startup work.

Several daemon startup phases currently start one goroutine per container and acquire the startup semaphore inside each goroutine. With many containers, that still allows an unbounded number of goroutines to sit behind the semaphore.

This acquires the existing semaphore before starting each worker goroutine at the affected startup phases while preserving the existing adjustParallelLimit(len(...), 128*runtime.NumCPU()) policy. If the semaphore cannot be acquired, startup paths now return that error instead of silently skipping work. The swarm restart path cannot return an error, so it logs the acquire failure and stops scheduling more restart work.

The registration pass no longer mutates the iterated containers map from worker goroutines: failed registrations are collected under the existing lock and removed from the map after group.Wait(). The container restore pass uses group.Go for consistency/readability. The container restart phase is left on the old shape because it has notifier dependencies between restarting containers.

Release notes (optional)

Validation

• gofmt -w daemon/daemon.go
• git diff --check
• go test -tags 'netgo journald no_libnftables' ./daemon -run '^$' -count=1
• go test -tags 'netgo journald no_libnftables' ./daemon -count=1 timed out after 10m in existing TestIfaceAddrs/Multiple while waiting on netnsutils.SetupTestOSContextEx; this is unrelated to the startup semaphore changes.

no_libnftables was used because this local environment does not have libnftables.pc installed; without that tag the daemon package fails during cgo pkg-config discovery before reaching these tests.

Created with: Codex