release-24.1: upgrades: fix destructive upgrade bug that was introduced when permanent upgrades were flattened

[rafiss]

fixes #133519
Release justification: fixes a major bug

---

roachtest: add test to verify that permanent upgrades are not re-executed

This test shows that there is a bug in how permanent upgrades are
applied when upgrading from clusters that started on a version older
than v23.1.

Release note: None

---

Revert "upgrades: remove v22_2 compatibility"

This partially reverts commit 129d62a.

It also fixes the roachtest that was added in the previous commit.

In PR #119142, the permanent upgrades were flattened so that they
all have a version of 0.0-x. That means that the last element of
the permanentUpgrades slice has a version of 0.0-4. Clusters that were
bootstrapped with a version from v23.1.0 or later will have rows in
system.migrations for versions 0.0-x, since that is the version where
the permanent upgrades framework was introduced (in PR #119142).
However, clusters that were bootstrapped from a version
earlier than v23.1 will not yet have these rows in system.migrations for
versions 0.0-x, and those migrations will only be present under the
legacy startupmigrations key.

Release note (bug fix): Fixed a bug that could cause the password for
the root user to be deleted while upgrading to v24.1. This bug only
affects clusters that were initially created with a version of v22.2
or earlier.

The same bug could also cause the defaultdb and postgres databases
to be recreated during the upgrade to v24.1 if they had been previously
deleted.

[blathers-crl]

Thanks for opening a backport.

Please check the backport criteria before merging:

• Backports should only be created for serious
  issues or test-only changes.
• Backports should not break backwards-compatibility.
• Backports should change as little code as possible.
• Backports should not change on-disk formats or node communication protocols.
• Backports should not add new functionality (except as defined
  here).
• Backports must not add, edit, or otherwise modify cluster versions; or add version gates.
• All backports must be reviewed by the owning areas TL. For more information as to how that review should be conducted, please consult the backport
  policy.

If your backport adds new functionality, please ensure that the following additional criteria are satisfied:

• There is a high priority need for the functionality that cannot wait until the next release and is difficult to address in another way.
• The new functionality is additive-only and only runs for clusters which have specifically “opted in” to it (e.g. by a cluster setting).
• New code is protected by a conditional check that is trivial to verify and ensures that it only runs for opt-in clusters. State changes must be further protected such that nodes running old binaries will not be negatively impacted by the new state (with a mixed version test added).
• The PM and TL on the team that owns the changed code have signed off that the change obeys the above rules.
• Your backport must be accompanied by a post to the appropriate Slack
  channel (#db-backports-point-releases or #db-backports-XX-X-release) for awareness and discussion.

Also, please add a brief release justification to the body of your PR to justify this
backport.

[cockroach-teamcity]

This change is 

[srosenberg]

I wonder if should add mixedversion.MustUpgrades(x, y) (to the framework) since MinUpgrades will rot over time, i.e., as of v25.2.