Add linstor storage driver

[luissimas]

Description

This PR introduces a new linstor storage driver to enable provisioning of volumes backed by LINSTOR, as discussed in #564.

All storage driver features are implemented except for storage buckets. Storage buckets cannot be implemented natively on LINSTOR, and the most logical approach would be to fallback to the generic implementation like it's done for all drivers other than Ceph. We didn't go in that route due to the fact that today Incus considers that any remote storage driver supports an optimized implementation of storage buckets, but that's not the case for LINSTOR ( https://github.com/lxc/incus/blob/main/internal/server/storage/backend.go#L3827).

Although most driver features are implemented, not all of them are optimized using LINSTOR native capabilities. We fallback to the generic implementation in several cases, including:

1. Migration across different storage pools
2. Copying volumes with snapshots
3. Backups
4. Refreshing volumes

Closes #564

[luissimas]

We expect to send integration tests validating the scenarios in the next few days. I think we'll probably need some Linstor setup on the testing environment as well.

[stgraber]

There's a bunch of static analysis failure around code styling/formatting that should be pretty easy to handle.

[bensmrs]

I’m seeing a small race condition leading to a double execution of setupLinstor:

• getLinstor gets called until after the d.linstor == nil condition is checked
• setupLinstor gets called before err := d.setupLinstor() gets called
• setupLinstor gets called again by err := d.setupLinstor().

I’d put a synchronization here…

[luissimas]

Hey @stgraber just a quick update on the state of things. @winiciusallan, @bensmrs and I did a quick call about the current state of the implementation and the next steps. Here are the main takeaways:

1. @bensmrs is working on the CI tests for the driver
2. While looking at the tests, we've identified that the lack of support for storage buckets may be a block for merging this, at least from the test's perspective. Can you confirm that?
3. @winiciusallan will look into how much work would it take to support storage buckets in the linstor driver
4. Renaming volumes is most likely a block for merging. Our initial approach will be to use the volume ID in the Incus database as the Resource Definition name in LINSTOR. We'll need to check if the ID is available on all code paths that create the volumes. We also need to be aware of the 48 character limit on LINSTOR object names. @bensmrs is probably the best person to tackle this, as he is the most familiar with the Incus code base.
5. We still need to figure out a good way to validate that all Incus nodes also run the linstor-satellite service and that the node names are consistent between Incus and LINSTOR
6. I'll finish addressing @bensmrs's comments on this PR and then I'll check if it is possible to have multiple LINSTOR controllers managing the same set of satellites. I'm guessing that is not supported, but if it is, then we should set the controller connection string at the storage pool level rather than in a global config option