fix: report when docker cp silently writes nothing

[tas50]

Fixes #387.

The bug

docker cp cannot write into a mount. A destination under a tmpfs or a volume is written to the container's own filesystem layer, which the mount then hides -- and docker exits 0 with no output. The copy looks like it worked and the file is simply not there.

Confirmed at the Docker level (29.7.2), against a container run with --tmpfs /tmp:

--- cp file -> /tmp/x.txt:      exit=0  present=NO
--- cp file -> /tmp/ (dir form): exit=0  present=NO
--- cp -a file -> /tmp/y.txt:   exit=0  present=NO
--- cp to /var/tmp (control):   exit=0  present=yes

Nothing caught that, so the failure surfaced later and somewhere else. tmpfs: /tmp is how the Docker documentation suggests running systemd in a container, and the first sign was the next command failing:

-----> Converging <default-ubuntu-2404>...
       Preparing files for transfer
       Preparing script
       [Docker] Executing command on container
       /bin/bash: /tmp/docker-717663f4-1551-4b21-86a6-115762ba3bea.sh: No such file or directory
>>>>>> Converge failed on instance <default-ubuntu-2404>.

That names neither the copy nor the mount, and reads like the driver wrote a broken script rather than none at all.

The fix

The copy is checked, and reported where the cause is still known:

Failed to copy file ./.kitchen/temp/docker-<uuid>.sh to container. docker reported
no error copying it to /tmp, but the file is not there. `docker cp` cannot write
into a mount -- if /tmp is a tmpfs or a volume, set the transport's temp_dir and the
provisioner's root_path to a path that is not.

docker cp SRC CONTAINER:DEST copies into DEST when DEST is a directory and to DEST otherwise; which one happened is only known inside the container, so the probe makes that choice there rather than asking twice from the host. Both paths are passed to sh as arguments rather than interpolated, so nothing in either is read as shell syntax.

Windows containers are not probed. tmpfs is a Linux container feature, and docker cp against a Windows container is a separate code path in Docker that I could not try this against, so those keep the behaviour they have.

This diagnoses the failure rather than making docker cp work into a mount, which Docker does not support. The advice it gives is verified below.

Confirmation

Docker 29.7.2 (Docker Desktop 4.87.0, macOS/arm64), Test Kitchen 4.1.1, real ubuntu-24.04 containers.

Before -- /bin/bash: /tmp/docker-<uuid>.sh: No such file or directory, as above.

After, same kitchen.yml -- the error quoted above, raised at the copy.

Then taking the advice the message gives (transport.temp_dir: /var/tmp, provisioner.root_path: /var/tmp/kitchen), with tmpfs: /tmp still mounted:

       Transferring files to <default-ubuntu-2404>
       HELLO FROM PROVISIONER
       Finished converging <default-ubuntu-2404> (0m0.77s).

Regression checks, both still passing: an ordinary docker-transport converge with no tmpfs, and a converge over the default SSH transport.

rake style clean; rspec 313 examples, 0 failures (7 new).

[RulerOf]

Hey @tas50, if I'm Reading the patch correctly, this doesn't make tmpfs /tmp work, merely provides a more descriptive error message?