release-patch-setup: consider removing from autotests

[rdimaio]

release-patch-setup tests that PR changes can be merged to the latest release branch (example)

We initially discussed that we could make it output a warning result when it fails, rather than showing as a failure, but GH Actions does not have this feature yet (there is a feature request for it, and this is the best alternative I found, which results in the step showing as successful regardless, but prints out a warning in the job summary.)

While this check is useful, it seems that we're mostly ignoring its outcome at the moment, and we're not remediating it when it fails. Even though it executes pretty fast (failed in 17s in the example linked above), it can be a bit annoying to mark a PR as "failed" just because of this check.

I think we could safely remove it from the autotests for now, and possibly add it later on once GH Actions adds the warning outcome feature.

[rdimaio]

release-patch-test depends on release-patch-setup at the moment: https://github.com/rucio/rucio/blob/master/.github/workflows/autotest.yml#L206

I think release-patch-test can be removed as well; they're the same tests as test (https://github.com/rucio/rucio/blob/master/.github/workflows/autotest.yml#L144), but done on the release branch. I feel like it might be unnecessary to run these at the PR level; generally, if tests pass on the master branch, they will likely pass on the release branch too. I also think that, from the contributor's perspective, the only checks should be against the master branch; the cherry-picking/releasing workflow happens in "parallel" to PRs/developing workflow, and I think they should be decoupled.

@bari12 what do you think?

[bari12]

I agree. I think we should just remove both.
There is a small group of errors where the current workflow might give us "early detection" of an issue on the release branch, which a PR author could immediately address. But in any way, we will discover the issue after the merge once the cherry-pick is done, so it is really only an early-detection.

But the much more likely scenario is to have false-positive test failures, which are to no fault of the PR author.