BlueprintZoneConfig and friends should not have to impl Ord/PartialOrd

[davepacheco]

It's possible this is a bad idea and should just be closed.

This came up while reviewing #11236. There, we had to impl Ord on zone_type::Nexus, which required impl'ing Ord on "a set of external IP addresses". This felt weird to me -- what does it mean to define an ordering between two sets of IPs (which could have different sizes, overlapping IPs, etc.), and why should we need that? It turns out that the only thing depending on this was that BlueprintZoneConfig (which stores a zone_type::Nexus) impls Ord/PartialOrd, and that's only because it's contained in blippy Notes, which blippy wants to be able to sort. I've instead impl'd some custom logic in blippy to sort without looking at this data, since I don't think it affects the result. Then I removed Ord/PartialOrd from BlueprintZoneConfig and a few related types.

This is a little goofy and I'm not sure if there's a better way to do it. What it boils down to is that blippy notes have a kind, but this isn't a discriminant -- it's a variant with data that includes the details of the note. It needs to be able to compare them with Eq/PartialEq, and that should use all the fields, including these fields that I want to ignore while sorting them. That's not allowed. Rust requires that PartialOrd/Ord/PartialEq/Eq all agree. So instead, I've impl'd a separate little tree of compare_to() helpers that compare based on discriminants. (It's a tree, not just one, because Kind is itself recursive -- each of its variants has its own Kind enum.) One could imagine wrapping this up into a sort of AltOrd trait, but I didn't go that far here.

[bnaecker]

I think this seems like a good approach. I also don't have enough experience with blippy's reporting to know if this is different in any important way, so I don't think my approval counts for much.

Do we want to remove Ord and other traits further down the chain, to the types like OmicronZoneExternalFloatingIps, which started this?