BlueprintBuilder: don't hold on to PlanningInput

[jgallagher]

This builds on top of #9370 and is a big piece of #9238: as of this PR, BlueprintBuilder no longer holds a PlanningInput, which should reduce confusion on where a given bit of logic should live. Anything that needs the planning input to be decided now must be implemented in the planner.

BlueprintBuilder::new_based_on(..) still takes a PlanningInput argument, which I don't love but need to do some more work to figure out how (if?) to address. It uses it for a few things; I think I'd group them as:

1. Reassembling information about sleds that we knew in previous iterations but that aren't stored in the blueprint. (Specifically: the BaseboardId and subnet of each active sleds. This is the one that seems trickiest to tackle.)
2. Adding new, empty SledEditors for commissioned sleds that are present in PlanningInput but not the parent blueprint. (I think I'd make the case that new_based_on() shouldn't do this at all, and the planner should do it?)
3. Making a copy of a few fields that are present in the blueprint, but that are updated each time the planner runs based on potentially-newer values in PlanningInput. (Specifically: the cockroachdb fingerprint and the internal/external DNS generations. I think it would be fine for BlueprintBuilder to only copy the parent blueprint, and provide setters that the planner could use to update these to newer values.)

There's one hopefully-small-and-fine logical change in this PR that I'll point out below with some extra details.

[jgallagher]

This is the logical change I mentioned in the PR description: I removed this second check that we only pick a zpool that's also InService according to the planning input.

I believe this change should not affect any planner behavior. It always decommissions disks before potentially adding new zones, so any disks that are no longer in service in the planning input will also no longer be in service according to the BlueprintPhysicalDiskDisposition by the time we get here.

This change could affect some weirder tests that only go through BlueprintBuilder, but I'm hoping we don't have any that trip over that particular case. If we do I think I'd claim the test is probably in the wrong: it means they'd be decommissioning disks, not updating the disk config to match, then trying to add zones that require a trip through this method to pick an available disk.

[sunshowers]

This seems great to me, thanks for taking care of it. The logical change seems pretty reasonable to me.

[sunshowers]

How do we ensure the PlanningInput doesn't creep its way in here in the future?

[jgallagher]

I don't think there's any way to guarantee it, but: I'm working on a few more PRs to remove the need to pass it into BlueprintBuilder::new_based_on() at all. Hopefully at that point the bar for adding it back is pretty high.