Prevent custom storage volumes to be used more than once

[edlerd]

Issue description

In most cases, a custom storage volume with content-type block is assigned to only one instance. When assigning it to more than one instances, the result will be data loss.

The proposal is to ensure the storage volume is unused when it has content-type block and assigned to a new instance directly or via profile. If the volume is already attached to another instance (or would be attached to more than one) an error should be returned instead.

A config setting on the storage volume can be set to override this check, allowing for the rare use case that block storage should be accessible from multiple instances.

When the content-type filesystem is used on the storage volume, it can be freely assigned to many instances.

[mas-who]

Issue description

In most cases, a custom storage volume with content-type block is assigned to only one instance. When assigning it to more than one instances, the result will be data loss.

The proposal is to ensure the storage volume is unused when it has content-type block and assigned to a new instance directly or via profile. If the volume is already attached to another instance (or would be attached to more than one) an error should be returned instead.

A config setting on the storage volume can be set to override this check, allowing for the rare use case that block storage should be accessible from multiple instances.

When the content-type filesystem is used on the storage volume, it can be freely assigned to many instances.

For custom storage volumes with content-type filesystem created within a storage pool using the ceph driver, the same problem should be considered. The root of the issue is that if you activate the same ceph RBD on two systems concurrently then you can get corruption, unless the file system running on top of ceph RBD is cluster aware.

[tomponline]

We may be able to cherry-pick from lxc/incus#467

[tomponline]

Also note lxc/incus#529