Do we care that "rebooting" states will not be included here? Or are you okay having V2P rules basically ignore these instances until they start running?

Relatedly, this requires the instance state machine to be very careful to ensure that during a migration, the target VMM doesn't leave the Migrating state until we're sure that the instance is actually going to move there (and, similarly, when it does move the source needs to have moved out of the Running state). If we don't follow those rules, this query might match multiple VMMs and so return multiple rows. This could lead to, e.g., cutting out connectivity too soon during a migration (if both the source's and target's entries show up and the latter is given precedence).

I think it might be simpler to change the join so that it unambiguously chooses the instance's current active VMM:

SELECT <columns>
FROM network_interface n
JOIN omicron.public.instance instance ON n.parent_id = instance.id
JOIN omicron.public.vmm vmm ON vmm.id = instance.active_propolis_id
JOIN omicron.public.sled s ON vmm.sled_id = s.id
-- gjc: other JOIN conditions elided for brevity

This way no one has to worry about the order in which states are reached during a migration--when migration actually finishes, the active_propolis_id will get updated, and we can trigger a new query to get the instance's new location. WDYT?

(cc @hawkw as well for the lifecycle implications.)