to_disk on Windows

[lstocchi]

One of the first commands to implement on Windows is to_disk.
We should have a similar workflow as done on linux. This is my idea of it

• Phase 0: Check for existing cached disk image
  The current code uses extended attributes (xattrs) for handling the cache. On Windows this does not work as rustix cannot be imported. However, NTFS supports a kind of extended attributes (NTFS Alternate Data Stream) so we could try to use a library which is cross-platform (suggestions??), otherwise we should have a mechanism to store data in a sidecar metadata file or leverage the Registry.

• Phase 1: Validation and preparation
  This should work similarly to what we have on the main branch. NTFS supports sparse file so we could reuse the current code. The difference is that we need to create a temporary image. We first create a raw image and then convert it to a vhd/vhdx image.

• Phase 3 -5
  We create a new podman machine using hyper-v (which shares a volume where the final .vhdx image will be stored) and execute the code/scripts used for linux (maybe instead of using the source image as the installer environment we should use a custom image?), then we leverage qemu-img to convert the resulting .raw to .vhdx. The podman machine is deleted (or should we keep it there for bootc purposes and just stop it?) and the host is able to use the .vhdx for further operations.

[lstocchi]

I've been trying to run bcvk inside a hyperv machine and the image was generated fine.
For this test, I created a rhel linux vm using macadam and replicated what happens on a linux host basically.
Other than enabling nested virtualization on Hyperv, we need to make sure we use static memory and assign an appropriate amount. I tried with 10GB now. Dynamic memory could kill qemu anytime.

The slowest part has been the fetch of ostree layers - like 5mins. I would be curious to know which is the fetch avg time on linux. Maybe this can be optimized some way.

Eventually we should convert the image to .vhdx and move this on the win host.
Instead of sharing a volume (using 9P) which could be slow, we could attach an empty vhdx file to the guest, make qemu-img writes into it and have our final bootc image on the host. (still to verify)