Blueprint planner is overly conservative with respect to NTP zones and timesync

The planner is very careful to avoid doing anything with a sled on which it has just placed an NTP zone, which is well-commented inside of do_plan_add():

https://github.com/oxidecomputer/omicron/blob/fe9bc0dd8b6192017b20f033b8434b1e76852ba9/nexus/reconfigurator/planning/src/planner.rs#L501-L505

https://github.com/oxidecomputer/omicron/blob/fe9bc0dd8b6192017b20f033b8434b1e76852ba9/nexus/reconfigurator/planning/src/planner.rs#L545-L548

https://github.com/oxidecomputer/omicron/blob/fe9bc0dd8b6192017b20f033b8434b1e76852ba9/nexus/reconfigurator/planning/src/planner.rs#L594-L599

The final comment gets at the driving reason: avoiding sled-agent rejecting requests to provision zones because time isn't synchronized yet.

With zone startup now going through the config reconciler, sled-agent no longer behaves this way: it's fine to send a sled config that includes both a new NTP zone and a set of zones that depend on time being synchronized. sled-agent will start the NTP zone, and wait to start any zones that depend on timesync until after that new NTP zone is sync'd with its upstream. We could probably simplify do_plan_add() a fair bit based on this, although I think we would have to make some explicit policy decisions that today are implicit in "do nothing until time is sync'd" (e.g., are we willing to place discretionary services on a sled before it syncs time?).

Start in nexus/reconfigurator/planning/src/planner.rs at do_plan_add(), especially the comments and logic linked in the issue. Read how the config reconciler and sled-agent now handle new NTP zones alongside time-dependent zones. Define the policy for discretionary services before simplifying the planner, and consider the work complete when the planner no longer applies unnecessary synchronization restrictions while preserving the intended startup behavior.