docker: use native gRPC for supported local endpoints

[crazy-max]

• relates to / addresses Replace or update the grpc endpoint moby/moby#49836
• relates to Replace or update the grpc endpoint moby/buildkit#5927
• Related to Natively support gRPC on the docker socket moby/moby#50744
• supersedes, closes Add support for native grpc on the docker socket #3369
• supersedes, closes driver: support native grpc on the docker socket #3780

Automatically use native gRPC for supported Docker daemons over Unix sockets and named pipes, using the daemon support introduced in moby/moby#50744. Retain the legacy /grpc and /session transport for remote endpoints and daemons without native gRPC support, preserving Docker's existing TLS and SSH handling. Concurrent callers share a bounded capability probe, and failed or canceled probes remain retryable. Explicit authentication and authorization failures are returned without falling back.

[crazy-max]

Native gRPC currently bypasses Moby's authorization plugins. httpHandler.ServeHTTP dispatches gRPC requests directly to the gRPC server or extension proxy, bypassing the HTTP API handler where the authorization middleware is registered. Consequently, these requests do not pass through its AuthZRequest check.

This is why native gRPC remains opt-in here. Moby needs to enforce authorization before dispatching native RPCs, covering both local services and the extension proxy while preserving streaming behavior. Keeping Buildx on the legacy transport by default preserves its existing authorization path, but doesn't prevent other clients from accessing the daemon's native gRPC endpoint.

[thaJeztah]

The /grpc endpoint is deprecated; no need to make it opt-in. Buildx isn't responsible for protecting the API because anything already can do.

[crazy-max]

Removed the opt-in. I kept the DialMeta guard because Desktop uses X-Docker-Desktop-idle: background on the /grpc upgrade to let Resource Saver distinguish background connections from interactive builds (https://github.com/docker/desktop-build/pull/312). That's separate from Moby's authorization middleware. These clients retain the legacy transport until equivalent native gRPC behavior is supported and verified.

[crazy-max]

@tonistiigi I benchmarked the legacy transport against the native gRPC path introduced by moby/moby#50744 to address moby/moby#49836. Your concern about session performance is reproducible.

The comparison uses the same Engine 29.3.0 daemon and client dependencies: legacy /grpc + direct /session versus native gRPC + Control.Session, as used by this PR.

Transfer results below are medians of five measured runs after warmup, with execution order rotated and all exported contents verified. Each workload includes both uploading the files and exporting them locally.

Workload	Metric	Legacy	Native	Change
One 128 MiB file	Elapsed time	1.649 s	1.881 s	+14.0%
	Client CPU time	3.004 s	4.959 s	+65.1%
	Client allocated bytes	195.7 MiB	416.8 MiB	+113.0%
	Client allocation count	138,084	373,534	+170.5%
	Client GC cycles	9	44	+388.9%
	Control RPC p95 during transfer	1.640 ms	1.706 ms	+4.0%
4,096 files of 4 KiB	Elapsed time	1.027 s	1.066 s	+3.7%
	Client CPU time	2.010 s	2.506 s	+24.7%
	Client allocated bytes	52.2 MiB	106.7 MiB	+104.5%
	Client allocation count	550,950	848,034	+53.9%
	Client GC cycles	0	3	N/A
	Control RPC p95 during transfer	0.883 ms	1.143 ms	+29.4%
Idle ListWorkers, 200 calls	Mean latency	0.323 ms	0.303 ms	-6.2%

Allocated bytes are cumulative allocations, not peak memory usage. Control latency during transfers is the median of each run's p95. The small-file elapsed ranges overlap, so I wouldn't treat the 3.7% difference as a confirmed latency regression. The CPU and allocation increases are the stronger signal.

The native path drops the explicit session dialer, making BuildKit tunnel the session through Control.Session. Since the session already carries gRPC over HTTP/2, this adds another framing layer, copying, and allocation overhead. As a cross-check, retaining native control gRPC while restoring direct /session brought large-file client CPU back to 2.929 s and allocation count to 136,559, close to the legacy baseline.

These are focused local transport measurements, not full build benchmarks. Shared Bake sessions already use tunneling in some cases, so the results don't apply uniformly to every Bake workload. Daemon CPU/memory, high-concurrency behavior, remote endpoints, and Desktop wake/sleep behavior remain outside this benchmark.