migration,backupccl: deal with full cluster backup/restore and migration jobs

[ajwerner]

Describe the problem

In #59760 we introduce a job to run cluster version migrations. This is great because it offers many benefits of the jobs ecosystem like pausing and mutual exclusion. A downside is that a full cluster backup is going to pick up those jobs which may not be safe to resume on the restored cluster.

Possible Solution

I'm thinking a simple solution would be to encode the cluster id of the creating cluster into the job. Then, when the job is resumed on a different cluster, it can just error out.

Epic CRDB-8816

Jira issue: CRDB-3191

[ajwerner]

@dt should this be a GA blocker? I just realized this was missing triage labels :(

[dt]

I don't think so. We won't restore a newer cluster version to an older cluster thanks to #61737 so it's just be restoring to an older one, and then it'd migrate up, which is probably what we want. Maybe some weirdness if there are system tables that are not restored so they're post-migration and then we run that migration again, but so far all migrations have had to make themselves idempotent anyway.

There's still the issue of non-cluster restore and bringing a non-migrated table into a migrated cluster, but we're no worse off than we were before 21.1 I believe in that we still expect authors of such migrations to fix it during restore.

[github-actions]

We have marked this issue as stale because it has been inactive for
18 months. If this issue is still relevant, removing the stale label
or adding a comment will keep it active. Otherwise, we'll close it in
10 days to keep the issue queue tidy. Thank you for your contribution
to CockroachDB!