Spun out of questions raised in https://issues.redhat.com/browse/MCO-1324

I've moved it here for reference:

> sregidor@redhat.com raised a great point on the PR; some stubs may still be 2.2.0 and the cert controller does not handle upgrading them to 3.2. Removing this injection from the MSBIC may cause newer bootimages that only support spec 3 ignition to attempt to use a 2.2 stub and fail. This needs some further evaluation of the following scenarios:

• if the cert controller can determine that the stubs are 3+, we're in the ideal world
• if the cert controller can determine that the stubs are 2.2 and not upgradeable, should we
  1. make using the managed secret mandatory for all machinesets?
  2. indicate to the user that they should update their stub to 3.x manually as a one time process, so boot images and rotation can be supported? (perhaps a mechanism similar to the one proposed in MCO-1295)
  3. force a "clean" 3.x stub, and let the user add what they need after the fact?