daemon: opt-in capture of exec output through the container's logging driver - #53407

When an exec is created with CaptureLogs, its stdout and stderr are
copied into the container's logging driver, mirroring the container's
own startLogging: a logger.Copier is attached to the exec's stream
pipes in InitializeStdio, before the process output starts flowing, so
no early output is missed. Each captured message is stamped with the
exec's identity — an exec_id attribute plus the exec's Labels, sorted
for deterministic order — so log readers can attribute the output
without holding any state. CloseStreams waits for the copier to drain,
guaranteeing every captured line reached the driver before the exec is
reported as terminated.

The driver is shared with the container's stdio copier; drivers already
accept concurrent Log calls from the stdout and stderr copy goroutines,
the capture copier follows the same contract.

Create-time validation rejects CaptureLogs when the container's log
driver is "none": there is nothing to capture into, and silently
accepting would let the caller believe output is being captured.

For API versions below 1.56 the router rejects CaptureLogs rather than
dropping it — a client asking for capture must not believe it happened
when it didn't — while Labels, pure metadata, are dropped like
ConsoleSize is for pre-1.42 clients. Exec inspect reports the labels.

Healthcheck probes are execs too; they do not set CaptureLogs, so
their periodic runs keep out of the container's logs.

Signed-off-by: Nicolas De Loof <[email protected]>

Both file-backed drivers have a per-entry attributes slot in their
storage format — json-file's "attrs" object and local's protobuf Attrs
— but the write path only ever fed them the static logger-level
attributes computed once from log-opts, and dropped the per-message
Message.Attrs. The read paths already decode entry attributes back
into Message.Attrs, so persisting them completes an existing
round-trip rather than introducing a format change.

Per-message attributes are merged over the static ones. Messages
without attributes — the overwhelming majority — keep the zero-cost
static path: json-file only remarshals when a message actually carries
attributes, and local builds a fresh slice only in that case (appending
to the shared static slice would mutate its backing array across
messages).

This gives captured exec output its attribution: the exec_id and label
attributes stamped by the exec log copier survive storage and surface
through the log endpoints when details are requested.

Signed-off-by: Nicolas De Loof <[email protected]>

exec_create, exec_start, exec_detach and exec_die events only carried
the execID (and exitCode for die). With execs now able to declare
labels, attach them to those events so subscribers can attribute exec
activity — which tool ran what — without correlating execIDs through
inspect, whose records are in-memory only and pruned after exit.

Reserved event keys and container labels keep precedence over exec
labels: LogContainerEventWithAttributes already copies container labels
over caller-supplied attributes, and the reserved keys are merged last.

Signed-off-by: Nicolas De Loof <[email protected]>

Success-case coverage for CaptureLogs: an exec created with capture and
labels prints on both streams; the lines are then retrieved through the
container logs endpoint, on the right streams, stamped with the exec's
identity when details are requested. Also asserts exec inspect reports
the declared labels.

Error cases (log driver "none", pre-1.55 API rejection) are covered by
unit tests.

Signed-off-by: Nicolas De Loof <[email protected]>