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.

[ehelms]

@evgeni @Griffin-Sullivan Take a look, this is now rebased on the consolidation of the scenario to a single file

[Griffin-Sullivan]

I like the explicit listing. It's much more readable for someone like me who doesn't know the nuances of the codebase.

[ekohl]

Now the tags :pre_upgrade part is not used anymore. Should that be kept?

Also, after this find_checks is only used as add_steps(find_checks(:root_user)) which really is a single check. Should that be replaced by an explicit add_step(Checks::RootUser) as well and drop find_checks?

[ehelms]

Also, after this find_checks is only used as add_steps(find_checks(:root_user)) which really is a single check. Should that be replaced by an explicit add_step(Checks::RootUser) as well and drop find_checks?

I added a commit to address this.

[evgeni]

In #892 I've introduced a basic "test that the expected steps are present" check -- should that be enhanced to verify the change in here is valid?

[ehelms]

In #892 I've introduced a basic "test that the expected steps are present" check -- should that be enhanced to verify the change in here is valid?

I got some tests added over here -- #897
I figure I would try to add tests ahead of time and then that should help make this change cleaner.

[ehelms]

This now includes #897 to show that the tests work before and after

[ehelms]

Rebased and updated tests for this structure

[ekohl]

Looks like find_checks is now unused:

$ rg find_checks
README.md
336:    steps.concat(find_checks(:default))

test/lib/support/definitions/scenarios/present_upgrade.rb
18:      add_steps(find_checks(:default))
95:      add_steps(find_checks(:post_upgrade_checks))

test/lib/support/definitions/scenarios/missing_upgrade.rb
16:      add_steps(find_checks(:default))

lib/foreman_maintain/concerns/finders.rb
16:      def find_checks(conditions)

Time to drop it?

[ehelms]

Looks like find_checks is now unused:

$ rg find_checks
README.md
336:    steps.concat(find_checks(:default))

test/lib/support/definitions/scenarios/present_upgrade.rb
18:      add_steps(find_checks(:default))
95:      add_steps(find_checks(:post_upgrade_checks))

test/lib/support/definitions/scenarios/missing_upgrade.rb
16:      add_steps(find_checks(:default))

lib/foreman_maintain/concerns/finders.rb
16:      def find_checks(conditions)

Time to drop it?

I did now.

[ehelms]

Tests are passing - this is ready to go now.