tracking issue for closely-related issues around dataset deletion

[davepacheco]

There are several closely-related issues whose fixes we may need to sequence carefully to avoid creating new problems so I thought it'd be easiest to have a central discussion of that here in this tracking issue.

• reconfigurator does not try to remove expunged datasets #7304
• "datasets ensure" API in sled agent should remove unmatched datasets (eventually) #6177
• Reconfigurator "deploy datasets then zones" ordering will break for zone expungement #7309
• planner may need to work around durable datasets never being destroyed #7312

(There are some other issues that I think we can ignore for these purposes: #6066 and #7311.)

In particular:

• Fixing either 6177 or 7304 would have no practical impact until both are fixed.
• Fixing both 6177 and 7304 before fixing 7309 would break zone expungement (that's basically what 7309 is describing).
• 7312 is obviated by fixing 6177 and 7304.

[jgallagher]

Fixing either 6177 or 7304 would have no practical impact until both are fixed.

Small followup: we discovered later that this wasn't quite right. Fixing 7304 alone turned out to be important. If a disk on a sled was expunged, 7304 had to be fixed to avoid dooming PUT /datasets: sled-agent would report a failure when asked to ensure the existence of a dataset on an expunged disk. (More details in #7500.)

AFAIK the other points still hold, including that if we fixed 6177 now that 7304 is fixed, we would break zone expungement.