The server certificate is only valid for the IP and localhost today.
Adding the machine name lets a client verify the certificate by name,
which is what a certificate generated before the machine has an
address has to rely on. Split the cert generation and the copy of the
client material into the machine directory out of ConfigureAuth so the
create-time path can reuse them.

The key is generated before the instance is created, but was only
pushed with a separate Instances.SetMetadata call once the instance
existed, one more operation to wait for on every create. Put it in the
insert request for both the Instances.Insert and the BulkInsert paths.
SetMetadata stays for --google-use-existing, where there is no insert.

Provisioning today needs SSH after the machine is up: the server
certificate has the machine's IP in it, which only exists after the
driver's Create, so the certificate is generated then, copied over SSH
together with the CA and the dockerd drop-in, and dockerd is restarted.

Drivers that implement TLSBootstrapper and report the bootstrap as
requested get the CA, a server certificate issued for the machine name,
the server key and the COS dockerd drop-in before Create, to deliver
however the platform allows. libmachine then skips the SSH provisioner
and instead retries a TLS handshake against the Docker port until it
succeeds, with the machine name as ServerName. A certificate that fails
verification ends the wait at once, since no retry fixes that; a dial
timeout of two seconds keeps the loop responsive while a booting machine
still drops the connection.

auth.Options gets ServerName, persisted in the machine's config.json and
used by every TLS config libmachine builds, so `docker-machine ls`,
`config` and the connection check verify the certificate against the
name and not the address. Other clients read it from there.

Both RPC methods are optional: a plugin without them reports the
bootstrap as not requested and the create runs as before.

Attach the TLS bootstrap libmachine generates as instance metadata
(gitlab-docker-tls-ca, gitlab-docker-tls-cert, gitlab-docker-tls-key,
gitlab-docker-daemon-dropin) on both the Instances.Insert and the
BulkInsert paths. A unit on the machine installs them and restarts
dockerd; docker-machine never opens SSH during the create. The material
is kept in the plugin's memory between SetTLSBootstrap and Create, not
in the persisted driver state.

Rejected together with --google-use-existing, since there is no insert
to attach to. The COS readiness gate and URL are not checked in this
mode because the SSH provisioner does not run; the flag warns about it.

Start inserts a new instance on the existing disk when the instance
record is gone. The TLS material is only attached to the original
insert and is not persisted in the driver state, and COS keeps /etc on
a tmpfs overlay, so the new instance would boot without the
certificates or the drop-in and never open port 2376. Refuse the way
bulkInsert mode already does. Stopping and starting an existing
instance is unaffected: its metadata is kept and the unit reinstalls
the files on every boot.

The function generates the Google COS drop-in whatever the driver, so
say so in its name. ServerName is now set only after the driver has
accepted the bootstrap, so a create that fails before that does not
leave it in the saved config.json.

With TLS 1.3 the client's handshake completes before the server has
checked the client certificate, so a successful dial only proves the
server certificate. A drop-in pointing at the wrong CA would pass the
wait and fail on the first job. Do one GET /_ping on the connection and
require 200. A TLS alert from the server ends the wait at once, like a
server certificate that fails verification.

google: deliver the Docker TLS material as instance metadata, no SSH in the create path

See merge request !196

Merged-by: Vishal Tak <vtak@gitlab.com>
Approved-by: Vishal Tak <vtak@gitlab.com>
Reviewed-by: Vishal Tak <vtak@gitlab.com>
Reviewed-by: GitLab Duo <gitlab-duo@gitlab.com>
Co-authored-by: Igor Wiedler <iwiedler@gitlab.com>