instance: add support for dual-stack network interace

[lgfa29]

Still a WIP, but I want to check if the acceptance tests are now passing in CI so opening it as a draft.

Relates to SSE-141

---

Incoming wall of text for what's missing.

I need to write more tests and figure out the upgrade path to avoid an in-place upgrade (which could the instance to restart) or full instance replacement. I tried to avoid a state migration, but I don't think there's a away around it. And even with a state migration achieving this could be tricky.

The main issue is that we don't know, from an old state, if a network interface was created with an empty IP address (auto mode) or an explicit IP. Since ip_address is Computed + Optional, in both cases we will have a value in the attribute.

When migrating to the new schema, the user could have one of the two configs:

# Auto IP address.
resource "oxide_instance" "auto" {
  network_interfaces = [{
    # no ip_address
  }]
}

# Explicit IP address.
resource "oxide_instance" "explicit" {
  network_interfaces = [{
    ip_adress = "10.1.2.3"
  }]
}

When migrating to the new version, they would need to update their config file to look like this in each case:

# Auto IP address.
resource "oxide_instance" "auto" {
  network_interfaces = [{
    ip_stack = {
      v4 = {
        ip_assignment = "auto"
      }
    }
  }]
}

# Explicit IP address.
resource "oxide_instance" "explicit" {
  network_interfaces = [{
    ip_stack = {
      v4 = {
        ip_assignment = "10.1.2.3"
      }
    }
  }]
}

But both old configs generate the same state, where ip_address = "10.1.2.3" (or whatever the auto IP was), and so we have two options for the migration:

1. we always set the new attribute ip_assignment to the old ip_address value.
2. we always set the new attribute ip_assignment to "auto".

Regardless of the option we choose, we'll break the other. For example, going with option 1 will force all users to update their configs to the explicit IP address config above, even if they created the instance with auto-assigned IP.

One thing that I thought about, but that I need to investigate more, is to try and make v4.ip_assignment optional, and so users that are migrating to the new version could use an empty v4 = {} block to indicate that we don't know the IP assignment is. We could then possibly use a PlanModifier to figure out the right value to use, but I'm not really sure if it will be possible.

---

Pull request checklist

• Add changelog entry for this change.

[linear]

SSE-141 Release the Terraform Provider