want /system/hardware APIs to say where the thing is physically located

While looking at the existing /system/hardware/sleds/{sled_id} and /system/hardware/switches/{switch_id}, I was somewhat saddened to discover that neither of these endpoints currently return an API model that includes the physical location of the sled or switch (i.e. what cubby the sled is in, or whether it's switch 0 or switch 1). This seems like a pretty big deficiency, since the operator can see the VPD identity of the thing, but cannot see where it is located, which is information that is accessible from Wicket but not in the console. This will become more important as the fault management subsystem starts to use the switch and sled UUIDs to indicate which switch/sled is impacted by an Active Problem (see #11029).

I suspect that in the sled case, it is possible that it's currently like this because the omicron.public.sled table does not include the slot number. This is because it is possible (though relatively unlikely) for a sled to join the control plane before an inventory collection has inventoried its SP, meaning that it is possible to briefly know who it is but not where it is. However, I don't think this should block us from ever including the location in the API. We could either make the slot field an Option and not populate it until it's known, or not return a sled in the list until we know where it is, or something?

Incidentally, I also noticed that the APIs for switch ports identify which switch the port is on by the physical location (switch0 or switch1), and don't include the UUID of the switch. So there is actually no way to go from the switch API model and look up the ports on that switch, at time of writing.

Sigh.

Start with the /system/hardware/sleds/{sled_id} and /system/hardware/switches/{switch_id} API entry points, then compare them with the switch-port APIs. Determine how sled and switch physical location should be represented when sled inventory is not yet known, and how ports should identify their switch. Done means the API models expose location and allow a switch to be related to its ports.