[pve-devel] [PATCH v8 storage 0/9] backup provider API

[Wolfgang Bumiller]

v7: https://lore.proxmox.com/pve-devel/20250401173435.221892-1-f.ebner@proxmox.com/

I picked this up since Fiona is currently not available.

This contains 1 "major" change (and incorporates some minor doc feedback
from Max (sans the `=head` rewrite, feel free to send follow-up patches
for this @Max).

The change is that instead of having a 

    sub backup_vm_available_bitmaps($self, $volumes)

which fills bitmap names into the passed-along $volumes array,
there is now a

    sub backup_vm_query_incremental($self, $volumes)

which should *return* a new hash (as modifying parameters is a bit
awkward if a plugin is not written in perl, eg. our rust perlmod...),
which instead of bitmap *names*, contains bitmap *modes* which are:

    - new: create a new bitmap, or *recreate* an existing one
    - use: use an existing bitmap, or create one if none exists

Bitmap names have two issues:
1. It is not clear if they are actually useful.
2. They do not provide a way to distinguish between the above modes.
   If the backup provider loses access to a drive which used a bitmap
   before, the only way to recreate it was to *rename* it, which meant
   keeping track of those names.

   So now the only thing we need to keep track of, which for some backup
   providers can *probably* happen without any extra state, is which
   drive a bitmap is relative to.
   Tracking names on the other hand is quite an awkward interface.

Changes in v8:
- storage: replace backup_vm_available_bitmaps() with backup_vm_query_incremental()
- qemu: add an explicit optional 'bitmap-mode' parameter to
  qmp_backup_access_setup()
- qemu-sever: adapt to the storage api change and pass the bitmap-mode
  to the qmp-backup-access-setup command
- storage: adapt directory example
- storage: change the previous-info file to be a json hash mapping disks
  to their last backups
- qemu-server: fix 'bwlimit'/'bwlimiit' typo
- qemu: fix a leak on error in `get_single_device_info()`

build order:
1. qemu
2. storage
3. a) qemu-server: depends on qemu + storage
   b) pve-container: depends on storage
4. manager: depends on qemu-server/container I guess