In prep for usage in MCD.

This is prep for fixing RHEL9 upgrades while maintaining `kernel-rt`.

Previously the `switchKernel` logic tried to carefully handle
all 4 cases (default -> default, default -> rt, rt -> default, rt -> rt).

But, the last one (rt -> rt) never actually did anything because
in fact the previous `rpm-ostree rebase` command already did it,
and invoking `rpm-ostree upgrade` here was always a no-op.

To say this another way: when doing a RHEL9 update, it's actually
the first `rpm-ostree rebase` command which fails before we
even get to `switchKernel`.

And the reason is due to the introduction of a new `-core` subpackage;
xref https://issues.redhat.com/browse/OCPBUGS-8113

So here's the new logic to handle this:

- Before we do the `rebase` operation to the new OS, we detect
  any previous overrides of any packages starting with `kernel-rt`
  and we remove them.
- The `rebase` operation will hence start out by deploying the
  stock image i.e. with throughput kernel (though note we *are*
  carefully preserving other local overrides)
- The `switchKernel` function now longer needs to take the *previous*
  machineconfig state into account!  Instead, we just detect if
  the target is RT, and if so we then do the overrides there.

This significantly simplifies the logic in `switchKernel`, and will
help fix RHEL9 upgrades.

This attempts to build on https://issues.redhat.com/browse/COS-1983
to test switching to RHEL9 (CoreOS) by default.

Unfortunately rpm-ostree requires this right now; we have an issue
and code to provide a better API in coreos/rpm-ostree#2542
But using that will require shipping the updated rpm-ostree in RHEL 8.6.z
or at least OCP 4.12.z, which is problematic.

Because we know the new MCD will always be upgrading to RHEL9,
for now let's update this hardcoded list.  In the future we can
detect when the running host has `--remove-installed-kernel` and
use it instead.

Rapid file changes triggering the path unit can start the
service here frequently, and then this can cause the start
limit to be hit, and then systemd will refuse further
activations (unless we bumped the limit).

I don't think we need to synchronize the iptables
rules more than once every 3 seconds.

When we move from RHCOS 8 -> RHCOS 9, the SSH keys are not being written
to the new location because:

1. When the upgrade configs are written to the node, it is still running RHCOS 8, so the keys are not being written to the new location.
2. The node reboots into RHCOS 9 to complete the upgrade.
3. The "are we on the latest config" functions detect that we are indeed on the latest config and so it does not attempt to perform an update.