driver/kubernetes: close exec-stream pipes when the stream ends

[pgimalac]

Ensure the far ends of the command exec pipes are properly closed when the exec stream ends (due to an error or not), to prevent infinite hangs in reader/writer.

Currently, if the remote kubernetes executor gets killed, buildx just hangs forever because it tries to read from pipes which are never closed. With this change, the pipes are immediately closed when StreamWithContext finishes, and readers/writers are unblocked.

Refs #556.

Added some unit tests to highlight the fix.

Repro / testing

Setup:

# create kind cluster
kind create cluster --name buildkit-repro

# create a builder
docker buildx create --driver kubernetes --name kindbuilder --driver-opt namespace=default,replicas=1 --bootstrap

Create a Dockerfile which takes some time, eg.:

FROM alpine:latest
RUN echo "step1 starting" && sleep 120 && echo "step1 done"

and build it:

docker buildx build --builder kindbuilder --progress=plain -f Dockerfile .

Wait for the log to show that it's running the sleep step, then open a new shell and kill it:

POD=$(kubectl get pods -l app=kindbuilder0 -o jsonpath='{.items[0].metadata.name}')
kubectl delete pod "$POD" --grace-period=0 --force

The build command will then hang forever (in particular won't finish after 2 minutes).

Now build cmd/buildx from this PR, and re-run the same steps using this buildx binary instead of docker buildx, you should observe that the build command logs err="io: read/write on closed pipe" when the pod is killed, and fails with the following error:

ERROR: failed to build: failed to receive status: rpc error: code = Unavailable desc = closing transport due to: connection error: desc = "error reading from server: command terminated with exit code 137", received prior goaway: code: NO_ERROR, debug data: "graceful_stop"`

[crazy-max]

Fixes #556.

Since #556 originally reports the docker-container driver and this PR fixes the Kubernetes exec path, Refs #556 may be more accurate than Fixes #556 unless the original docker-container hang is known to be covered elsewhere.

[pgimalac]

#556 originally reports the docker-container driver

@crazy-max yeah fair, I figured it was a catch-all for both (in particular considering the last message is about kubernetes), but I'll update the description.