firmware: want more distinctive boot option names

[iximeow]

the UEFI boot options for disks are named UEFI , UEFI 2, UEFI 3, and so on. in some circumstances, like the EFI shell, it's a bit difficult to get at the disk's serial number, which is where i'd find a prefix of the disk's name as known in the control plane. in other circumstances it's just hard to correlate options f.ex from efibootmgr with what disks they refer to.

EDK2 includes logic that would distinctively name NVMe devices by their model and serial numbers, but because we provide a model number containing nulls, the serial number ends up not included at all, and the auto-determined description is just UEFI . i've described this procedure in (excruciating) detail over in this test about it.

as-is we provide a serial number and not a model number (see this nvme list output from a real instance). if EDK2 were changed to replace nulls with spaces when copying model/serial number fields in BmGetNvmeDescription , BmEliminateExtraSpace would collapse runs of extra spaces and we could have nice boot option names like UEFI your-disk-name-here. or we could figure out what a full 40-character model number could be for our emulated NVMe controllers, and the stock OVMF build would be sufficient.

nice as this may be, we must not change boot option descriptions without doing something like #787, handling UEFI variables more intentionally as described towards the end of RFD 470, or having a compatibility procedure to leave old VMs unaffected. if a VM is booted and boot option descriptions change from options stored in its UEFI boot variables (which may be preserved in guest disks' EFI System Partitions), real bootable disks may end up after the EFI shell and leave affected VMs in a state like Omicron#5112

[rmustacc]

We shouldn't fight UEFI with respect to the NUL characters. See #790 for more information on what's incorrect in Propolis. There are likely still improvements to be made, but that at least gets us out of the EDK2 changes.