Description of problem:

During backup, when guest write data that is part of the backup, qemu 
coopies the old data from the disk to the scratch disk before writing to the 
data to disk. When the scratch disk becomes too full, vdsm need to extend
the disk.

Libvirt will support monitoring scratch disk block threshold in RHEL 8.4
(bug 1913315). Here is an example of backup xml showing the scratch disk
deails:

$ virsh backup-dumpxml backup-test
<domainbackup mode='pull'>
  <server transport='tcp' name='localhost' port='1234'/>
  <disks>
    <disk name='vda' backup='yes' type='file' backupmode='full' exportname='vda' index='4'>
      <driver type='qcow2'/>
      <scratch file='/tmp/backup-test-images/scratch-vda.qcow2'/>
    </disk>
    <disk name='hda' backup='no'/>
  </disks>
</domainbackup>

Vdsm need to extract the name ('vda') and index (index='4') and use them ("vda[4]") as the name argument to virDomain.setBlockThreshold().

After starting backup, vdsm need to set write threshold on the scratch disk.

When handling block threshold event, vdsm need to mark the scratch disk for
extension, and schedule async extend operation.

Async extend operation need to send an extend message to the spm, and wait
for extend reply.

If an extend request fails or times out, vdsm need to retry and send a new
extend request.

When the scratch disk is extended successfully, vdsm needs to refresh the
volume, and set a new block threshold.

This mechanism is similar to the way normal disks are extended, but the
current mechanism assumes that only the top volume of the disk is monitored
or extended, so it cannot be used as is.

If vdsm was restarted during a backup, it may miss the block threshold event,
so it needs to query the allocation of the scratch disk, and trigger an
extend if needed. To check the current allocation we can use the bulk stats 
API (virConnectGetAllDomainStats/virDomainListGetStats) as "block.
<num>.allocation" in the VIR_DOMAIN_STATS_BLOCK group. The current threshold
value is reported as "block.<num>.threshold".

The size of the chunks and the threshold can use the existing configuration
(irs:volume_utilization_percent, irs:volume_utilization_chunk_mb).

Same mechanism is needed also for live merge and live storage migration.

- In live merge, we use only initial extension. This may not be enough for
  merging the active layer. In this case live merge will fail and the user
  will have to retry the merge.

- In live storage migration we have complicated mechanism monitoring the
  source disk and extending the target disk. This can be replaced by
  monitoring the target disk and extending it separately.

This will be hard to implement and may require more than one zstream cycle.