add YouCanBootAnythingAsLongAsItsAlpine image source

[jmpesp]

For development purposes, allow people to select the alpine.iso blob that ships with the propolis-server zone image as an image source.

[jmpesp]

Unfortunately this doesn't seem to boot through through the default NVMe device emulation. This can be reproduced with:

    wget https://oxide-omicron-build.s3.amazonaws.com/OVMF_CODE.fd
    wget https://oxide-omicron-build.s3.amazonaws.com/alpine.iso
    qemu-system-x86_64 \
        -bios OVMF_CODE.fd \
        -machine pc-i440fx-focal \
        -m 1g \
        -drive file=alpine.iso,if=none,format=raw,id=nvme1 \
        -device nvme,drive=nvme1,serial=nvme-1,addr=0x4

[jmpesp]

Note the original propolis config used the "pci-virtio-block" device.

[jmpesp]

Unfortunately this doesn't seem to boot through through the default NVMe device emulation.

I should be more clear - it does boot to a UEFI shell. If you enter FS0:\efi\boot\bootx64.efi, it does take you to a grub prompt, and fails to boot further. On the serial console:

Mounting boot media failed. 
initramfs emergency recovery shell launched. Type 'exit' to continue boot
sh: can't access tty; job control turned off
/ #

I suspect this is due to a missing NVMe module.

[jmpesp]

The latest alpine-virt-3.16.0-x86_64.iso does boot with the qemu invocation above (specifically, through NVMe).

[jmpesp]

I've updated our alpine.iso to alpine-virt-3.16.0-x86_64.iso, and now the above qemu invocation works, and booting an instance using a disk based on

~/cli/cli.sh api /images --method POST --input - <<EOF
{
  "name": "alpine",
  "description": "boot from propolis zone blob!",
  "block_size": 512,
  "source": {
    "type": "you_can_boot_anything_as_long_as_its_alpine"
  }
}
EOF

works too.