fix: stop defaulting disk_type to pd-standard

[tas50]

What

Removes pd-standard as the default disk_type so that newer GCE machine series work out of the box.

Why

DISK_DEFAULT_CONFIG set disk_type: "pd-standard" on every disk. Newer machine series reject it:

Machine series	Supported disk types
N1, N2, E2, T2, M1	pd-standard, pd-balanced, pd-ssd
C3, C3D, M3	pd-balanced, pd-ssd, Hyperdisk — no pd-standard
C4, N4, A3, Z3, M4	Hyperdisk only — no Persistent Disk

So machine_type: n4-standard-2 with no disks block passed all of validate! — the disk type is valid in the zone, just not for that machine; validation is per-resource, not per-combination — and then failed at insert_instance with a raw API error.

How

Send no diskType unless the user configured one. GCE then substitutes the default for the instance's machine series, per the AttachedDiskInitializeParams.diskType contract in the Compute v1 discovery document: pd-standard for first- and second-generation series, pd-balanced for C3/C3D/M3, hyperdisk-balanced for C4/N4 and newer.

This keeps the driver's existing design — machine types, disk types, networks and images are all validated against the live API rather than a hardcoded list — instead of adding a machine-family table that would go stale with each new family. The two alternatives considered were defaulting to pd-balanced (still fails on C4/N4, and silently changes the disk type for every existing N1/N2 user) and a family-prefix table in the driver (predictable, but duplicates a mapping Google already maintains).

Three call sites needed to stop treating an absent type as an error:

• valid_disk_type? used nil → false as a null-guard, conflating "absent" with "invalid". Fine while absent was impossible; wrong once it became the default. Now valid, and skips a get_disk_type call per run.
• legacy_disk_config built its hash with explicit keys, so dropping the default yielded disk_type: nil instead of no key. Now carries the key only when set.
• Both disk-creation paths set the type field only when configured — otherwise the boot disk would get the malformed partial URL zones/<zone>/diskTypes/.

Compatibility

No behaviour change for N1/N2/E2/T2/M1 users: GCE's default there is also pd-standard, so no silent disk-type or cost change. C3/C3D/M3 now get pd-balanced and C4/N4/A3/Z3 get hyperdisk-balanced where they previously got a hard failure.

Known limitation

Extra non-boot disks are created as standalone disks before the instance exists, so GCE has no machine series to derive a default from and falls back to pd-standard regardless of machine_type. On C4/N4, disk_type must be set explicitly on those disks. Solving this properly needs the family table this PR deliberately avoids, so it is documented in the new "Disk types and machine series" README section with an N4 example rather than worked around.

Testing

bundle exec rake — 297 examples, 0 failures; chefstyle clean on 18 files.

Six specs were written failing first:

• default boot disk normalises with no disk_type key
• an explicit type on one disk does not leak as another disk's default
• deprecated partial config fills the rest without inventing a type
• only the user's own type is passed to get_disk_type
• inline boot disk sends no diskType
• standalone extra disk sends no type

plus the existing valid_disk_type?(nil) spec flipped to the new contract.

Not verified against a live GCE project — the machine-series mapping comes from the google-apis-compute_v1 0.153.0 generated docs (Google's own discovery document), which is authoritative for API behaviour, but a real kitchen create against an N4 instance would be the actual proof.

🤖 Generated with Claude Code