update_nvram does not set grub/update_nvram in debconf in target system

Curtin makes various efforts to control what happens to the UEFI boot order during installation. For example grub.update_nvram will prevent changes being made at all (module bug #2002085) whilst grub.reorder_uefi will make Curtin reshuffle the boot order post-grub-install to restore the boot device used for installation (e.g. to ensure it remains as PXE boot).

After installation however, updates to the grub-efi-* packages will automatically trigger the grub installer to be re-executed. Unless the grub/update_nvram debconf variable is changed from its default of 'true' to 'false', this will result in the UEFI configuration being modified, moving the installed system disk to the first position.

In the cases where either grub.update_nvram is false or grub.reorder_uefi is true this feels like unexpected behavior. For example in MAAS-style environments where it is essential that the first boot device be a network boot, an update to grub-efi-* would result in a mass escape of control.

As such, it seems to me that in the above cases Curtin ought to set the grub/update_nvram debconf variable to false in the target system to avoid this kind of surprise.

Alternatively, ought this default behavior in Ubuntu's grub package be considered a bug? The auto-running of grub-install only occurs when an existing grub installation is detected by the grub installer -- i.e. it only occurs during updates. This default behavior seems generally quite harmful in general. It also seems unnecessary since the UEFI entry for grub is essentially stable across updates.