So we're kind of wedged on letting the MCO use the new format image because there isn't really a "use if it's there, ignore it if it's not" way of getting the images into the payload: 

1. We need to add new images to the payload – `rhel-coreos-8`,`rhel-coreos-8-extensions`,`rhel-coreos-9`,etc ( this is not the problem ) 
2. We also need the MCO to know those images are there and use them (this is the problem) 
3. There is an imagestream file in the mco called `image-references` 
4. The openshift client uses this file to determine: 
          - which images are required to be in the payload
          - which image registries/namespaces it needs to overwrite in the payload manifests with the proper values from the release payload 
5. We can't add the image to image-references right now because then `oc` will require it (this is how we broke layering branch builds)
6. Since we can't add it right now,  openshift client will not rewrite any entry we put in the `machine-config-osimageurl` configmap, which means it will be eternally defaulted and the MCO can't retrieve the real value
7. (We also can't just hard-code the new image in the MCO because everything everywhere will just use it regardless of what's actually packed in the payload, which will break lots of things I'm sure if someone cuts a release)

We have some options: 

1. For now, just detect whether `machine-os-content` is a new format image and "overload" machine-os-content (obviously doesn't help us for extensions)
2. Wait until the ART work completes and the images are available / put the code in as-is but inert and turn it on when ART is done
3. Somehow have the live MCO inspect the image reference file directly to find the image, and ignore all of the `machine-config-osimageurl` configmap stuff
4. Other, open to suggestions

  
Additional things to consider that might affect the plumbing here:

• Since we're going to have rhel 8 and rhel9 images in the payload at the same time, I could see someone wanting to choose which version at the pool level, which makes me think they should all be available in the controllerconfig (or somewhere) as a list.
• I don't know that I want to just regex/prefix check it and say "any images that start with rhel-coreos in the payload and up in controllerconfig", but that's my straw man for now. Otherwise we get to go in every time there's a new release and hard-code another value. 

Acceptance Criteria:

• We know know whether we need to wait for the ART images and what work we need to do in the mean time.
• Any additional required cards are created for this  work.