Add the GCP management network for Postgres - #6623

The management VPC holds only the management NICs of GCP Postgres VMs.
Its firewall policy gets no tag-targeted rules and no VPC-wide RFC1918
deny rules. Instead, two untagged rules allow tcp/22 from the IPv4 and
from the IPv6 entries of control_plane_outbound_cidrs, one rule per
address family like the VPC-wide deny rules, and two rules deny all
IPv4 and IPv6 egress.

The firewall is stateful, so SSH replies still pass. The egress deny
keeps a fenced server from sending anything through its management NIC:
no WAL to the timeline bucket, no replication, no client traffic, also
when the guest gets a default route on nic0 back from DHCP. It also
keeps the management NICs of two servers from reaching each other.

An update_firewall_rules on the management VPC re-applies these rules
instead of pushing VpcUpdateFirewallRules, so a change of
control_plane_outbound_cidrs reaches the policy. The SSH rule of an
address family with no CIDR is removed.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Prog::Vnet::Gcp::SubnetNexus.assemble_management creates the management
subnet of a GCP location in the Postgres service project, at
100.64.0.0/20, with its strand. The strand then creates the dedicated
VPC, its rules and the GCE subnet through the paths of the previous two
commits. It does not use Prog::Vnet::SubnetNexus.assemble, which always
attaches a firewall to the new subnet: Vm#private_subnet_firewalls joins
through every NIC, so that firewall would apply to the VM of every
management NIC.

The range is outside RFC 1918 because every customer subnet is in RFC
1918, and GCE rejects an instance whose NICs have overlapping subnet
ranges, also when the subnets are in different VPCs. The same range
serves every location: each location has its own management VPC, and
the VPCs are not peered.

The insert ignores a conflict on the (project, location, name) unique
index, and the strand is created in the same transaction, so a second
call, also a concurrent one, returns the existing strand. The operator
runs it once per location; the E2E setup will run it once per run.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

random_private_ipv4 splits a subnet into at most 2**8 blocks and gives
each NIC one block, a /28 in a /20. So the /20 management subnet would
hold only 256 NICs, one per Postgres server of a location. The new
PrivateSubnet#random_host_ipv4 picks a single /32 anywhere in net4
outside the addresses the provider reserves, which gives the management
subnet 4,092 addresses. It checks a candidate with a lookup on the
unique (private_subnet_id, private_ipv4) index of nic instead of loading
every NIC of the subnet.

NicNexus.assemble uses it for NICs in the GCP management subnet. It
locks the subnet row first, so two assembles never pick the same
address; the unique index backs that up.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Vm::Nexus.assemble passes management_nic_use_eip: false for a
management NIC that the control plane reaches over IPv6, and the AWS
NIC prog then allocates no EIP. The GCP NIC prog ignored use_eip and
reserved a static external IPv4 for every NIC. Such an address would
never be attached, so it would cost the unattached rate and count
against the regional address quota for nothing.

The GCP NIC prog now hops to wait without a static IPv4 when the
frame's use_eip is false. A frame without the key keeps the old
behavior, as on AWS. Today only AWS and metal callers pass use_eip:
false (GitHub runners), so no GCP NIC changes until GCP management NICs
exist.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>