[DO NOT MERGE] - expands skip-ignition-apply work in MCD

[cheesesashimi]

This is meant to expand on @dkhater-redhat 's work around skipping the ignition apply path in the MCD in this PR: https://github.com/openshift/machine-config-operator/pull/4871/files . My work is intended to be cherry-picked into Dalia's PR and expanded upon.

Here's how this works:

1. Once we've determined that we need to do an update, triggerUpdate() is called. This is where we effectively "merge" the OCL and non-OCL update paths.
2. Within triggerUpdate(), we embed the OCL image pullspecs into the MachineConfig, overriding the OSImageURL value. The reason we override this value is because many of the update functions use OSImageURL as their source of truth.
3. Once we get to the end of the update path, we extract the OCL image pullspecs from the MachineConfigs and store them on disk in the expected place.
4. Once the node reboots and finishes the update, it looks at those expected files and determines what it needs to do. A benefit of doing it this way is that other than the embed and extract functionality and carving out a path within the applyOSImageUpdates() function (which was already done in a separate PR), only minor code changes were necessary.

A few notes about the implementation:

• The triggerUpdate() and triggerUpdateWithMachineConfig() methods were consolidated into a singular code path for both OCL and non-OCL paths.
• The canonicalizeMachineConfigImage() function was renamed to embedOCLImageIntoMachineConfig() and refactored to set a few annotations in the case that it embeds an image into the MachineConfig by overriding the OSImageURL value. A companion extractOCLImageFromMachineConfig() was also implemented that will revert the OSImageURL back its original value on-demand. Both functions will perform a DeepCopy of the MachineConfig so that the mutations we make are not reflected in the lister cache.
• It is worth mentioning that these annotations are only applied to the MachineConfig through the execution path of the MCD. They're not even written to the nodes' filesystem. The MachineConfig API objects on the API server are not updated with these annotations because they're not useful outside of the MCD.
• The aforementioned embed and extract functions are used in two places: 1) The newMachineConfigDiff() function where it extracts these values to determine if OCL is enabled. 2) Before storeCurrentConfigOnDisk() is called.
• Unfortunately, many of the MCD's code paths require testing against a live cluster and I did not have the opportunity to do that. That said, I've added unit tests where prudent. However, it is possible that the unit tests do not reflect reality within a live cluster. However, our e2e-ocl suite, particular around rollouts and reverts, should be able to exercise the code paths I have changed.
• In the future, we should instead standardize on using the OSImageURL field on the MachineConfig objects. This will allow the MCD to stop making a distinction between OCL and non-OCL since there will only be a single path.

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cheesesashimi

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [cheesesashimi]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment