[reconfigurator] Add "pruneable zones" to PlanningInput

[jgallagher]

This builds on the BlueprintExpungedZoneAccessReason added in #9608, and adds a new set of zone IDs to PlanningInput for "pruneable zones". These are zones that the planner is safe to prune in a future planning iteration, because they are:

1. Expunged and ready for cleanup
2. No longer needed by the rest of the system, implying any necessary cleanup is done (e.g., Nexus zones no longer have any assigned sagas/support bundles) and any relevant information has been replicated elsewhere (e.g., external DNS IPs have been reused)

This PR only adds the new set of zones to PlanningInput. It will be nearly trivial to add a step to the planner to "prune all zones present in the planning input's pruneable_zones set", but out of an abundance of caution I'd prefer to land this first, collect a reconfigurator state from some deployed racks, and confirm the contents match what we'd expect on some real systems.

This is a little weird in that the logic for whether a zone can be pruned lives in the "prepare a planning input" crate rather than the planner itself, but I think this is reasonable given the implementation of several of the checks (e.g., "query CRDB for this expunged zone specifically" to see whether it's still referenced, which the planner can't do since it doesn't have access to CRDB). Happy to discuss alternatives if this seems wrong upon review.

(We may also want to wait on #7278 before adding the actual prune step?)

[jgallagher]

I was originally going to add a couple blippy lints that any zone in expunged_and_unreferenced is (a) present and (b) actually expunged, but with the guard in this method and the fact that PlanningInput's fields are private, I don't believe it's actually possible to construct a PlanningInput with any such zone IDs in expunged_and_unreferenced, so it was impossible to write a test to confirm the blippy lints triggered.

[davepacheco]

Nice! This is really clean. I've commented on one possible bug here and the rest is nitty feedback.

[davepacheco]

I don't know enough about this to evaluate this case -- may want to ask @karencfv or @andrewjstone to double-check.

[karencfv]

I think it should be fine? I'd like to get @andrewjstone's thoughts on this though just to be sure

[andrewjstone]

This looks good to me. I just read some of the code to remind me what is going on, and if there is no zone there, it means it must have been expunged. Since that's mainly what this PR is about, the same zone with random uuid is not coming back magically.

[jgallagher]

Bunch of changes here (enough it's probably easier to rereview than look at the diff?):

1. Rename "expunged and unreferenced" to "pruneable" throughout
2. Add the runtime-built set of reasons checked plus a test that asserts they're all covered, as described in [reconfigurator] Add "pruneable zones" to PlanningInput #9730 (comment)
3. Add a whole bunch of tests that cover all the "zone not pruneable" reasons we check (this was LLM-assisted and is quite a bit of code, but I think not an unreasonable amount for what it's doing?)

[davepacheco]

Still looks great. Just minor suggestions here.

[davepacheco]

Sorry for racing with the change here. Let me know if you want help merging it.

[jgallagher]

No problem; it was not a bad merge at all.

[davepacheco]

nit (as I write this, I'm really not sure it's better): what do you think of using strum to iterate SupportBundleState variants so that you can use the match at L315 to actually construct this Vec? Just making it a little less likely that somebody would update one and not the other.

[jgallagher]

Done in 40916cd; I do think it's better.