Generally modifying storage volume/pool settings require removing and
creating the object again. This is not only API limitation, but most of
them really need the object to be recreated (for example storage pool
have most settings related to physical location of the data).
But some properties are safe to change. This applies to
`revisions_to_keep` (both storage pool and volume). Introduce
appropriate API methods for this. Put property name in API call name,
because argument is already used. And also because we don't plan to be
too flexible here - we may need to add one or two more mutable properties,
but definitely we don't want to allow any of them (as explained above).
The same applies to `persistent` option of device. There, in theory
detach+attach should be enough at all times, but in practice domain may
use the device (for example system being started from it -
QubesOS/qubes-issues#3055).
It is needed for VM clone operation: we have volume.Import, but not
volume.Export - at least not yet. And doing export+import would be very
inefficient, especially on smart storage pools (like LVM).
1. Drop separate admin.vm.microphone.* calls - lets use
admin.vm.device.mic.* for this. Yes, this means microphone cannot
be attached to multiple VMs at the same time (which is regression vs
Qubes 3.2). But this is a good thing from security point of view.
2. Drop admin.backup.Restore - use standard Admin API methods
(admin.vm.Create, admin.vm.volume.Import etc)
Cc: @kalkin
