sdc-migrate migrate should set indestructible_zoneroot=false

[jbarfield]

As the title states, sdc-migrate migrate does not update the indestructible_zoneroot boolean in the vmadm manifest on the source compute node. Subsequently this causes migrations to fail and leave both vm's and sdc-migrate list in degraded states.

To reproduce:

• Provision a VM with --deletion-protection using node triton cli.
• Login to the headnode and run sdc-migrate migrate <uuid of vm>.
• Wait for all steps to complete...the final step will fail.
• sdc-migrate abort will also fail complaining that there is no such job.
• The source and destination vm's will remain in a stopped state.

To resolve the issue, you must perform the following steps:

• 1st login to the destination compute node.
• Start the new VM and verify that the migration was successful. (Note that I have not had a destination migration be unsuccessful). But I like to make sure that it is properly booted without data loss and running with the most up to date data on disk.
• Next login to the source compute node.
• Run vmadm update <uuid> indestructible_zoneroot=false
• Do your own checks (SOP) before the next step, to be sure that you're ready to delete the source VM. Then run vmadm delete <uuid>.
• On the headnode sdc-migrate abort <uuid> inevitably fails so you have to manually delete the migration like so:
• sdc-vmapi /migrations/<uuid> -X DELETE
• I have had in the past, at least sometimes, to run: svcadm restart vm-agent vminfod on the destination compute node to be sure that the VM shows up properly in triton. (adminui for sure, but didn't test other interfaces)

Updated the description to note other mention able facts after discussing with Brian in IRC:

• The destination VM does get indestructible_zoneroot=true set properly.
• This appears to be a regression of: https://smartos.org/bugview/TRITON-2127
• TRITON-2127 was resolved in Triton release-20200521
• Currently my "sdc-vmapi" release is at version: release-20220825-20220825T003215Z-g6ac7d1c
• "cn-agent" version: 2.14.7
• Note: the brand exhibiting this behavior is "bhyve".
• The Triton platform version that the behavior was detected on is: "20220825".

I did not document the following well at the time of the error but I saw something to the effect of:

• sdc-migrate failed: zfs set quota=0 failure on (either source or destination VM). I wish that I had copied the error.
• The aforementioned is not a supported command in zfs. The correct syntax is zfs set quota=none zones/<uuid>