Change upgrade test to still use the older version of tests

[GuptaManan100]

Description

This PR reverts the changes made to the upgrade tests in #16494. The situation has evolved as follows -

1. Prior to changes in Improve the queries upgrade/downgrade CI workflow by using same test code version as binary #16494, we would always run the code in the branch for both upgrade and downgrade tests. This caused us to add SkipIfBinaryBelowVersion lines whenever we added a new feature, because the older binaries wouldn't support them, and downgrade tests would fail without them.
2. In Improve the queries upgrade/downgrade CI workflow by using same test code version as binary #16494, we changed both upgrade and downgrade tests to use the code in the other branch. So, on main running downgrade tests would run tests from v20.0, and running upgrade tests from v20.0 would run tests from main. This caused a different issue where when we add a new test, it doesn't run in downgrade on main, and everything works, but then upgrade tests from v20.0 would run this new test (since it uses main code!), and the test would fail there! So, we had to add the SkipIf... lines later.
3. In this PR we propose to use the older version code for running both upgrades and downgrades. This means that the upgrade tests don't change, but the downgrade tests should use their own code instead of the upgrade version's code. This would give us the best of both worlds. When we add new tests we won't need to add SkipIf.. lines because we're going to use the downgrade versions code for testing. And we won't run into the issue where a test passes in the original PR, but then fails when we create a different PR against v20.0, because when running upgrade tests in v20.0 we would still use the v20.0 code. This means that the upgrade tests from the previous release, and downgrade tests from the current release are symmetrical. So, if a test were to fail, it would fail on main.

Related Issue(s)

Checklist

• "Backport to:" labels have been added if this change should be back-ported to release branches
• If this change is to be back-ported to previous releases, a justification is included in the PR description
• Tests were added or are not required
• Did the new or modified tests pass consistently locally and on CI?
• Documentation was added or is not required

Deployment Notes

[vitess-bot]

Review Checklist

Hello reviewers! 👋 Please follow this checklist when reviewing this Pull Request.

General

• Ensure that the Pull Request has a descriptive title.
• Ensure there is a link to an issue (except for internal cleanup and flaky test fixes), new features should have an RFC that documents use cases and test cases.

Tests

• Bug fixes should have at least one unit or end-to-end test, enhancement and new features should have a sufficient number of tests.

Documentation

• Apply the release notes (needs details) label if users need to know about this change.
• New features should be documented.
• There should be some code comments as to why things are implemented the way they are.
• There should be a comment at the top of each new or modified test to explain what the test does.

New flags

• Is this flag really necessary?
• Flag names must be clear and intuitive, use dashes (-), and have a clear help text.

If a workflow is added or modified:

• Each item in Jobs should be named in order to mark it as required.
• If the workflow needs to be marked as required, the maintainer team must be notified.

Backward compatibility

• Protobuf changes should be wire-compatible.
• Changes to _vt tables and RPCs need to be backward compatible.
• RPC changes should be compatible with vitess-operator
• If a flag is removed, then it should also be removed from vitess-operator and arewefastyet, if used there.
• vtctl command output order should be stable and awk-able.

[GuptaManan100]

Since we don't run Downgrade tests in main, I've created a PR against release-20.0 to see these changes work - #16938

[GuptaManan100]

It works as intended, since I can see in the test output for upgrade tests in #16938, we aren't running TestOverallQueryTimeout which wasn't available in v20.0