docker+machine: verify the daemon certificate against the machine name

Summary

The docker+machine executor verifies the daemon's certificate against the machine name when docker-machine says so. It reads ServerName from the machine's auth options and sets it on its docker client.

Why

gitlab-org/ci-cd/docker-machine!196 (merged) adds --google-cos-tls-via-metadata. The server certificate is generated before the VM exists, so it cannot contain the IP and is issued for the machine name instead. Clients keep dialing the IP and have to verify the certificate against the name. Without this change the executor fails the handshake on such machines with certificate ... doesn't contain any IP SANs.

What changes

The credentials lookup reads the machine's auth options as JSON from the one docker-machine inspect call it already made for the certificate directory, and takes the server name from the same output. Machines without one, either provisioned over SSH or created by an older docker-machine, verify against the IP as before. The field is in memory only, not a config option.

In the sandbox, 20 fresh-VM jobs passed on machines created with the docker-machine flag, and the same runner build served machines created without it.

Why no feature flag

The switch is docker-machine's --google-cos-tls-via-metadata in MachineOptions. Machines created without it have no ServerName and this code does nothing for them, so a runner flag could not change behaviour for any existing setup. It also could not roll the metadata path back: the certificate on such a machine has no IP in it, so a runner that ignores ServerName fails every handshake. Rolling back means turning the docker-machine option off, which works without a flag. The one change that runs for every machine is reading the auth options as JSON instead of a single field, and json has been an inspect template function in docker-machine since long before the fork.