Reconsider automatic archiving of releases

[yulianedyalkova]

Current problem: some customers go through the same upgrade path for all clusters and it doesn't always include the latest minor/patch of a major. Example situation and sequence of events:

• 33.2.0 was the latest 33.x release when customers tested the upgrade path and started applying it to some of their clusters
• the 33.2.0 clusters got upgraded to newer versions but some clusters still lagged on versions <33.2.0 (so the release was not in use)
• eventually we created 33.4.0 and deprecated and eventually archived 33.2.0 as it fit all criteria for doing that
• once they tried to upgrade their clusters (quite later than the dev ones), the release was already gone

Possible solutions:

• Do not archive releases if there is a smaller active release still
• Ensure exceptions for releases to skip (but then we need to be aware of those and track them, prone to mistakes)
• Something else?

Acceptance criteria:

• Deprecate but do not archive releases if there is a smaller active release
• Ensure deprecation doesn't affect cluster upgrades in any way