[sled agent] Figure out how to store/manage Service Bundles

[smklein]

#1598 proposes extracting service bundles from zones, and putting them somewhere in the global zone.

Service bundles would presumably include log files, and they'd take up disk space, which is a finite resource.

This issue tracks coming up with a design for:

• Determining where to store these bundles
• Determining how to apply backpressure when they consume excessive disk space
• Determining how to extract the bundles off-device + make them useful for inspection

[smklein]

As discussed in the 10/28 Control Plane Huddle, it would be nice if this storage mechanism could also store coreadm dumps too

[leftwo]

Specifically we need configuration and storage of both core files, and kernel dumps (coreadm and dumpadm)
Both of these are dynamic, in that the location where things will be stored is on an SSD that could be removed or fail.
The configuration will need to be updated to reflect whatever new location is decided on.

[jclulow]

Note that in the kernel crash dump case, we probably don't need to update the dump save location like we do with coreadm. There is at most one crash dump per OS boot (if the OS crashed again we overwrite the dump device in place), which we can save at an explicit moment with savecore(8). Once that's done we don't need to do it again until next boot.

We do need to make sure an appropriate slice on one of the M.2 devices is configured as the dump device though, via dumpadm(8), and that might change one of the devices fails while the system is up, say -- but otherwise those are not hot-pluggable.