commands: stop dial-stdio when the builder connection closes

[crazy-max]

fixes #3668

Fixes a dial-stdio hang that could persist after the builder connection closed. The command now exits when the read side finishes instead of waiting for a new write on stdin to unblock the process.

The old code used two io.Copy calls and waited for both to finish, which meant a blocked read from stdin could keep the command alive even after the builder connection had already died. This showed up when the Docker daemon restarted and dial-stdio stayed hung until the user pressed Enter.

Tried to add an integration test for this but that's tricky. We would need some wiring with explicit restart/kill hook into the worker to test this regression. So needs changes in BuildKit test framework imo.

cc @invidian @cpuguy83

[tonistiigi]

This kind of leaves the reader in unknown state. Normally you would read to io.Discard in here but not sure if it would hang.

[crazy-max]

This kind of leaves the reader in unknown state. Normally you would read to io.Discard in here but not sure if it would hang.

I simplified this by removing the cancelable reader wrapper entirely. The proxy now starts the two io.Copy directions directly and waits on their completion channels.

When stdin finishes first, it closes the connection write side and keeps waiting for remote output. When the remote side finishes first, it closes the read side and returns immediately, so dial-stdio no longer hangs on a blocked stdin read.

That avoids leaving the original reader in an odd state, since we no longer put a pipe reader in front of it or try to cancel it from the outside. I also removed the extra errgroup, so the implementation is much closer to the original copy-loop shape.

I tested it on a real remote builder by closing the connection.

[cpuguy83]

Sorry, I don't recall this one coming in.
LGTM.

[cpuguy83]

Doesn't seem necessary.