want sled-agent timeout on completion of requests to stop a Propolis VM

[gjcolombo]

Today, requests to stop a running instance must by necessity involve the instance's active Propolis (sled agent sends the stop request to Propolis; the instance is stopped when Propolis says so, at which point sled agent cleans up the Propolis zone and all related objects). If an instance's Propolis is not responding, or there is no active Propolis, there is no obvious way to clean up the instance and recover.

A short-term workaround is to grant some form of API access to sled agent's "unregister instance" API, which forcibly executes the termination path (tearing down the Propolis zone and removing the instance from the sled's instance table) and can get force an instance into a stopped state.

In the long run instance lifecycle management needs to be made more robust to Propolis failure and/or non-responsiveness.

[jordanhendricks]

Related: #3209

[gjcolombo]

In #4194, sled agent's "instance unregister" API assumes that it can produce the correct posterior VMM and instance states by emulating a "Propolis destroyed" state transition. (That is, sled agent's "rudely terminate this instance" function computes the next state by pretending that it immediately got a message from the current VMM that says "I am destroyed and my current migration has failed.")

This is fine today because the unregister API is only used when unwinding start and migrate sagas, where the VMMs that are subject to unregistration have by definition not gotten to do anything interesting yet. It's less fine if Propolis has already begun to run, and especially not fine if we're force-quitting an instance that's a migration target:

1. Source and target VMMs agree that migration is done
2. Just before they tell their respective sled agents, Nexus shows up and rudely terminates the source
3. The emulated "VMM destroyed, migration failed" transition retires the source and the migration, which makes it possible to start the instance again...
4. ...but the target might actually begin to run while this is happening!

This seems dangerous. We probably want to adjust the synchronization here to be something more like the following:

1. Nexus "disowns" a particular VMM, e.g. by replacing its ID in an instance record with a zeroed ID (or some other set of sentinel values that prevents the instance from restarting)
2. Nexus terminates all of the disowned VMMs
3. Nexus clears out the sentinels to allow the instance to start again

This would need to be done in a saga to ensure the whole process runs to completion. More design work's needed here. We just need to do that work before we hook up any external APIs to the existing instance_ensure_unregistered sled agent interface.

[davepacheco]

Also related: #4872