docker-podman: stricter container ID regex to avoid bad matches

[AdamWill]

In testing an environment using the docker provider backed by podman-docker, I kept running into a problem where the first time I tried to bring up a container it would fail because it tried to use 'sha256:3' as the container ID. A second attempt to bring up the container would always succeed.

On inspection, I think this is happening because, for some reason, the output from the 'docker build' command had a line:

Copying config sha256:368a084ba17dcba88f5b23acfa47481131010219524fd9c41af87d709a04845b

after the line it wants to match on (a line containing just the final container ID). This happens almost every time on one host I'm testing on (which is a Fedora 38 host); it doesn't seem to happen on the other host (which is Fedora 39). I'm not sure why. But we can fix it by just tightening the regex a bit, to only match on a line that starts with a 64-character alphanumeric string, not any line that contains one.

[hashicorp-cla]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

_{Have you signed the CLA already but the status is still pending? Recheck it.}

[AdamWill]

Apologies, I don't really know Ruby, so I don't know how to wrap the mock stdout output bit to two lines, if line length is an issue :)

[AdamWill]

This is the last few lines of output Vagrant was using, I believe (I added a raise Errors::BuildError line like the one further down to get it to dump the output right after getting it):

STEP 10/10: CMD [ "/usr/sbin/init" ]
COMMIT
--> 3ae0ddcee7f5
3ae0ddcee7f5de7af3994734876c16f81d321f35d4a7c5f8bc1793458917c09b
 Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
Resolved "fedora" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull registry.fedoraproject.org/fedora:latest...
Getting image source signatures
Copying blob sha256:718a00fe32127ad01ddab9fc4b7c968ab2679c92c6385ac6865ae6e2523275e4
Copying config sha256:368a084ba17dcba88f5b23acfa47481131010219524fd9c41af87d709a04845b
Writing manifest to image destination
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100   409  100   409    0     0   6810      0 --:--:-- --:--:-- --:--:--  6932

Note, I was running podman system reset between attempts to get as clean an environment as possible. The problem may not occur if you don't do that, as podman will have some stuff cached.

[AdamWill]

I can't sign the CLA without my employer (Red Hat) reviewing it first. I have asked for that review. I suspect the change is small enough not to be copyrightable anyway, but I don't know if you want to merge it on that basis.

[AdamWill]

aaaand the legal department reminded me Vagrant is no longer F/OSS, which I'd totally forgotten about.

Given that, I'm not inclined to sign the CLA. If you want to take the commit as uncopyrightable, I won't complain.