Move downgrade test into separate CI job

[bgilbert]

Package downgrade detection runs as part of continuous-integration/jenkins/pr-merge, which is a required check. As a result, when it fails, only repo administrators can merge the PR. Consider moving the check into a separate CI job which isn't marked required.

[dustymabe]

Consider moving the check into a separate CI job which isn't marked required.

Since the results of the build are essentially thrown away (not used) I'm wondering how we get the information in a different job without doing a new build.

[bgilbert]

We could still have the test physically happen as part of the existing job. But instead of failing the job if the test fails, we could directly drive the GitHub checks API to report success/failure as a separate check.

[jlebon]

OTOH if we don't make it part of a required check, it's easier to ignore/miss (you enable auto-merge and walk away, never knowing that a downgrade has happened).

Cases like #2414 are in fact not super common. The test failures here happened in cloud tests, which aren't part of the bump-lockfile checks. The majority of the time, that's not the case and we pin to versions before the lockfiles moved forward (so no downgrade technically has a chance to happen).

If we really want to catch this case, we could have the CI check not error out if the downgrades are from pin overrides (like #2414) since that's our way of expressing we really do want those specific package versions and the PR was reviewed on that basis.

For things like major version rebases where downgrades sometimes happen in the base lockfiles, it's reasonable to block on a repo admin to merge.