clusterversion: remove V23_1 checks

[RaduBerinde]

Remove all IsActive checks for 23.1 version. Note that this code
could/should have been removed in the 24.1 cycle.

Epic: none
Release note: None

[cockroach-teamcity]

This change is 

[rail]

Reviewed 45 of 45 files at r1, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @celiala, @dt, @nameisbhaskar, @nkodali, @vidit-bhat, and @wenyihu6)

[celiala]

thank you!!

Reviewed 45 of 45 files at r1, all commit messages.
Reviewable status: complete! 2 of 0 LGTMs obtained (waiting on @dt, @nameisbhaskar, @nkodali, @vidit-bhat, and @wenyihu6)

[RaduBerinde]

bors r+

[craig]

Build failed:

• unit_tests

[RaduBerinde]

I had a mistake in restore_job.go. I did a bit of refactoring to remove the flag that is now always set and remove dead code. @dt or @msbutler could you take a look over the backupccl changes?

[dt]

Hmm. The restore changes raise an interesting question about resuming jobs from older versions and indeed about whether we can delete old minted cluster versions at all.

the upgrade system ensures that if you observe this version that all nodes are on new code, stay on newer code and migrations run. Currently there is no migration that fails or wait or anything if an older job still exists in the jobs system.

the check in restore that is deleted here is not a IsActive check that we known is always true, but rather a check to see what version created the job since that will mean different fields can or cannot be relied on.

In theory we could expect to see a job created by 23.1 in any future version, long after 23.1 is below min version, unless we write a migration to block upgrades or something.

So while we can delete IsActive gates that are noops due to being below min supported, I’m not sure we can delete the actual minted cluster versions while there is still code comparing them to versions persisted in something like a job?

[RaduBerinde]

Ok, I will revert those changes and leave V23_1. But note that the relevant code won't be tested at all.. (that would probably require some fixtures generated from other branches).

Maybe the safer thing would be to fail the job if the version that created it is less than MinSupported?

[dt]

Yeah, I wonder if jobs should just do that by default and long-lived jobs should be responsible for hauling up the “creation” version in vX if they know they’re the same in vX as vX-1

[RaduBerinde]

Ok, for now I am leaving that code alone and I filed #124351.

[RaduBerinde]

TFTR!

bors r+

[craig]

Build succeeded:

• unit_tests
• linux_amd64_build
• docker_image_amd64
• windows_build
• examples_orms
• check_generated_code
• macos_arm64_build
• local_roachtest_fips
• linux_amd64_fips_build
• local_roachtest
• lint
• macos_amd64_build
• linux_arm64_build
• acceptance