Guest external IP configuration needs to be dual-stack

[bnaecker]

Today we send the external IP addresses for a new instance to the sled-agent through the [InstanceSledLocalConfig]:

omicron/sled-agent/types/src/instance.rs

Lines 63 to 73 in 552ab0f

	pub struct InstanceSledLocalConfig {
	pub hostname: Hostname,
	pub nics: Vec<NetworkInterface>,
	pub source_nat: SourceNatConfig,
	/// Zero or more external IP addresses (either floating or ephemeral),
	/// provided to an instance to allow inbound connectivity.
	pub ephemeral_ip: Option<IpAddr>,
	pub floating_ips: Vec<IpAddr>,
	pub firewall_rules: Vec<ResolvedVpcFirewallRule>,
	pub dhcp_config: DhcpConfig,
	}

That has exactly one optional SNAT IP configuration, exactly one optional Ephemeral IP, and any number of Floating IPs. We need to instead support dual-stack external addressing here. This means wrapping all three of these fields into an address-version-specific struct, and then stuffing that into an enum that has the IP version in it, or the concept of a dual-stack NIC.

That way, we can validate the VPC-private addressing (IPv4-only, IPv6-only, or dual-stack) against the external IP addressing for the instance, at the time we construct the request in Nexus. We could consider making the whole IP stack an enum like that, where each enum variant contains the VPC-private and external IPs, all of the same version. But that's a big change.

Also note that it's important to make this change backwards-compatible with the existing wire format for these requests. During an update, a new sled-agent may get an instance-ensure request from an old Nexus. It must be able to correctly deserialize that, even if we change the in-memory representation to be more strongly-typed.

[jgallagher]

Also note that it's important to make this change backwards-compatible with the existing wire format for these requests. During an update, a new sled-agent may get an instance-ensure request from an old Nexus. It must be able to correctly deserialize that, even if we change the in-memory representation to be more strongly-typed.

The OpenAPI manager / versioning work will force this backwards compatibility, and it doesn't require that the new type be backwards-compatible on the wire with the old type. New sled-agent still has to accept the old format, but it can be via an entirely separate endpoint. #9076 is an example - it's a much smaller change than what this issue requires, but shows the mechanics of adding an ignition_get_v1() endpoint that returns an old type while changing the type that ignition_get() returns to something new and not backwards compatible on the wire.