persistentnetnamesdisable and addupgradebootentry actors, etc. need to be more thorough in its handling of kernel command line arguments

[sloanebernstein]

We have noticed that once CentOS 7 has been upgraded to AlmaLinux 8 through leapp, subsequent kernel updates do not appear to receive the bootloader entry modification requested by the persistentnetnamesdisable actor. This required us to issue two separate updates to work around this issue, namely cpanel/elevate#195 and cpanel/elevate#205, but we think that these problems can still happen with leapp on its own and should thus be addressed upstream of our project.

The first change was based on the observation that net.ifnames=0 did not (always?) make it into the GRUB_CMDLINE_LINUX setting in /etc/default/grub when it did make it into the bootloader entry of the kernel leapp installed. leapp only appears to touch that setting if something emitted a GrubConfigError message which the addupgradebootentry actor read.

The second change was based on the observation that even if net.ifnames=0 makes it into /etc/default/grub, that is not sufficient to allow newer kernels installed after the upgrade to see this command line argument. As best as I can tell, the reason for this seems to be that although new kernels do run grub2-mkconfig as part of the framework which handles all the minutiae of configuring the new kernel to be booted, it does so with the --no-grubenv-update flag, which is a problem because the new kernels always specify their command line arguments as a reference to the $kernelopts environment variable, whose update this flag explicitly prevents. By contrast, the kernel leapp installs hardcodes all of its command line arguments in the bootloader entry file, which may be reasonable or even necessary during the upgrade but is probably not appropriate afterwards.