Reject MGS driven update for bootloader when using known un-updateable device

[karencfv]

Once the RoT bootloader pre-checks and post-update actions for MGS driven updates have been implemented in #8325, we'll want to add additional pre-checks.

There are known bootloader FWIDs that don't have cabooses and older versions of the SP have a bug that prevents setting the active slot for the RoT bootloader. We want to have a precheck that rejects any update that matches those bootloader FWIDs or SP versions. While none of our production racks will have any of those devices, this will help dev experience if anyone is attempting to update using an old device.

[davepacheco]

Thinking about this more: I think execution is not the right place for this. If Reconfigurator should do anything here, it's probably the planner that should identify this situation and avoid configuring an update that won't be possible to complete. Otherwise, if we generate an error during execution, then this PendingMgsUpdate will never complete and the update will get stuck and require operator intervention...and I'm not even sure what intervention would be possible. One idea would be use the mechanism in #8284 to have the planner report something like "I can't update this device". But even then, we don't want the update getting stuck there either.

Here's another idea: what about a new background task that looks at the latest inventory and generates a list of "things to notify the operator about". Eventually I'd hope this could plug into the fault reporting stuff @hawkw has been working on. But in the meantime, it could report an event like "You have a device here running an unsupported software version. It needs to be manually updated to a newer version. In the meantime, the system will avoid updating it."