GCE allows creating an instance with no service account, in which case
the metadata server serves no access token. The driver always sent one
serviceAccounts entry, so there was no way to ask for that.

With the flag set, the instance request carries no serviceAccounts
field on both the Instances.Insert and the RegionInstances.BulkInsert
paths. --google-service-account and --google-scopes are ignored.

The readiness gate ran `cloud-init status --wait` through SSHCommand,
which fails on any non-zero exit. On stock COS (cos-121, cos-125,
cloud-init 24.4.1) that command never exits 0:

- While cloud-init is still running it exits 1 with "Failed due to
  systemd unit failure": cloud-init's systemd_failed() treats any
  cloud-init service that is not UnitFileState=enabled/static as
  failed, and COS leaves the four services disabled and pulls them in
  through cloud-init.target from the generator. This is the state
  docker-machine finds ~10 s after boot, so every create failed
  immediately.
- Once done it exits 2 ("degraded done") because DataSourceGCELocal
  raises UnboundLocalError in init-local (no DHCP client on COS) and
  cloud-init falls back to DataSourceGCE.

Neither is a failed boot, and nothing in user-data can change either.
The fleet image (COS 109, cloud-init 23.2.1) has neither check, which
is why the gate has worked on gprd.

Poll for /run/cloud-init/result.json, which cloud-final writes after
every module including runcmd has run, then run `cloud-init status`
once: 0 and 2 pass, 1 (errors recorded in result.json, e.g. a failed
runcmd) and 124 (our own 5 min timeout) fail the create. Recoverable
errors are logged at warn level.

cloud-init.target is the ordering point cloud-init documents for "all
stages done" (After=cloud-init.target). `systemctl start` on it blocks
until it is reached, returns at once if it already was, and returns 0
even when cloud-final failed, so `cloud-init status` afterwards still
turns a failed runcmd into a failed create.

Checked on cos-125-lts (cloud-init 24.4.1) and the fleet COS 109 image
(23.2.1) with a `runcmd: sleep 150`: the start returned 0 after 149 s
and 153 s, when cloud-final finished. With a failing runcmd it returned
0 after the sleep and status exited 1 with the scripts-user error.

The flag waits for cloud-init before Docker is configured; the old name
described the incident that motivated it. The old flag is kept as a
deprecated alias with a warning. The instance metadata key becomes
gitlab-wait-for-cloud-init; it is written and read by the same binary
and a machine is only provisioned once, so nothing depends on the old
key.

google: add --google-no-service-account

See merge request !194

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

# Conflicts:
#	drivers/google/google.go

google_cos: wait on cloud-init.target instead of `cloud-init status --wait`

See merge request !195

Merged-by: Igor <iwiedler@gitlab.com>
Approved-by: Vishal Tak <vtak@gitlab.com>