cmdline vars get corrupted when set via tuned

Description of problem:
A customer tried to add the following kernel args through tuned:
elevator=none

After generating again grub.cfg with grub2-mkconfig and rebooting, it leads to the truncated cmdline below:
<other args> =none

Version-Release number of selected component (if applicable):
2.02-87.el8_2.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Add a bootloader section into a tuned profile:

1. cat << EOF >>/usr/lib/tuned/virtual-guest/tuned.conf
   [bootloader]
   cmdline = elevator=none
   EOF

2. Enable that profile

1. tuned-adm profile virtual-guest

3. Generate grub.cfg

1. grub2-mkconfig -o /boot/grub2/grub.cfg

Actual results:
BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-193.28.1.el8_2.x86_64 root=/dev/mapper/rhel_foo-root ro crashkernel=auto resume=/dev/mapper/rhel_foo-swap rd.lvm.lv=rhel_foo/root rd.lvm.lv=rhel_foo/swap console=tty0 console=ttyS1,115200n8 systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M rd.debug crashkernel=256M =none

Expected results:
BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-193.28.1.el8_2.x86_64 root=/dev/mapper/rhel_foo-root ro crashkernel=auto resume=/dev/mapper/rhel_foo-swap rd.lvm.lv=rhel_foo/root rd.lvm.lv=rhel_foo/swap console=tty0 console=ttyS1,115200n8 systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M rd.debug crashkernel=256M elevator=none

Additional info:
When tuned is executed, the following line is added to `/etc/default/grub`:
~~~
GRUB_CMDLINE_LINUX_DEFAULT="${GRUB_CMDLINE_LINUX_DEFAULT:+$GRUB_CMDLINE_LINUX_DEFAULT }\$tuned_params"
~~~

It's added by _grub2_default_env_patch() in `/usr/lib/python3.6/site-packages/tuned/plugins/plugin_bootloader.py`.
I can note commenting out this line fixes the issue (but tuned will add it later dynamically as it runs as a daemon).
When this line is present, it affects the `kernelopts` variable from `/boot/grub2/grubenv`, $tuned_params is added at the end of this line after running `grub2-mkconfig`.

To fix permanently this issue, restoring the previous grubenv (that is to say, removing the "$tuned_params" in the kernelopts var) and then running grub2-mkconfig with the option below leads to the expected behaviour:
~~~

1. grub2-mkconfig --no-grubenv-update -o /boot/grub2/grub.cfg
   ~~~

Please also note using a first arg like "noop", which doesn't contain the '=' sign, does not lead to that issue.

This issue looks close to:
https://bugzilla.redhat.com/show_bug.cgi?id=1669252

Which has been fixed by the errata below:
https://access.redhat.com/errata/RHBA-2020:1869

But a more recent version is used in this case.