Fixes #37158: Explicitly define upgrade steps in upgrade scenario

[ehelms]

This is a draft as I am using it to help understand what is happening, to prune the set of checks, and to help decide if we want to move away from the "magic" and to a more explicit layout of these items.

Right now the design of foreman-maintain is to define metadata and in some cases constraints about a check and then have the system automagically figure everything out. This puts all the logic into the check but makes it harder to tell what is happening when you look at a scenario that is then using these.

There are a few other properties a check can define:

1. Conditions that must be met for a check to run (e.g. a package existing, or a plugin)
2. Before / after another check
3. A block of code (or even another check) that is executed prior to a check

Example:

    class CheckOld < ForemanMaintain::Check
      metadata do
        label :check_old_foreman_tasks
        for_feature :foreman_tasks
        tags :pre_upgrade
        description 'Check for old tasks in paused/stopped state'
        before :check_foreman_tasks_in_pending_state
        after :foreman_tasks_not_paused
      end

Initially, I am not a huge fan of #1 and #2 as this puts condition knowledge into the check, rather than letting the functions of the tool define when to run what and where. For things like upgrade scenarios, or health checks, or backup and restore I tend towards being as explicit as possible to make the code understandable both when debugging and performing new development. I think I would rather define a well defined list of checks for a given scenario and then use that within the top-level CLI functions. I do think the conditions (#1) can be useful if restricted to feature flag style only (e.g. feature(:foreman_proxy).dhcp_isc_provider?)

[ehelms]

I've added a Redmine and taken this out of draft. The idea is to move to explicitly stating the steps for each upgrade scenario for each phase rather than relying on the declarative structure to reconcile the set of steps. My view is that seeing these laid out explicitly makes it much easier to reason about and inform re-factoring and feature development. There are some steps that are conditional based on what's on the system and while they are explicitly steps in the upgrade they are not executed if their conditions are met.