[reconfigurator] remove the add-zones-with-mupdate-override planner config

[sunshowers]

While attempting to resolve #10420, we realized that the add-zones-with-mupdate-override config simply cannot result in a blueprint with coherent semantics in some cases.

Concretely, consider the situation where:

• a target release has been set at least twice (so both the old and new image sources are Artifact)
• a mupdate override is present on at least one sled
• there is a missing Nexus zone (which is a discretionary zone)

If this planner config is set, we would attempt to place a Nexus zone on one of the sleds. What version should it have?

• Currently, this is either the old Artifact image source or the new one.
• If we decide to place the zone on the sled with a mupdate override, then that produces a blueprint that both blippy and Sled Agent (for that sled) reject.
• But it would be very strange for the image source of the zone to be different based on the sled it is put on.

This planner config was not used in practice (documentation for our support team has no mention of it). I've left the infrastructure to add new planner configs in place, though -- happy to remove that as well if y'all feel like that makes sense. (Previously daft would not handle empty structs properly -- as part of this PR I've fixed that.)

This has no impact on racks that have never have a target release set -- for those racks, the image source is always InstallDataset so this is moot (and pre-existing code handles the "target release generation is one" case already).

Fixes #10420.

[jgallagher]

LGTM, just a couple very minor questions.

[jgallagher]

Maybe worth keeping this method if we're keeping PlannerConfig around? I don't have strong feelings either way about that, but if we think we might add fields to it in the future, we'd end up putting this method right back, I assume.

[sunshowers]

Yeah let's keep it for symmetry with get_planner_config.

[jgallagher]

Would this be slightly more futureproof if we kept planner_config in the destructure above, and added a

let PlannerConfig {} = planner_config;

here?

[sunshowers]

Ah so the thing is that what ends up here is PlannerConfigDiff which is a daft-generated type, not PlannerConfig. There is a PhantomData field within the diff struct that's kept private so it can't be destructured.