umbrella issue for cluster version migrations

[tbg]

• Acceptance testing.
• Update the RFC.
• Pave the way for future use of UseVersion < MinVersion, if still required.
• Migration that makes sure there's always a cluster version settings able
  entry migrations: persist the version setting for 1.1-initialized clusters #17389, disallow version bump if settings table has no value entry?
• Consider removing the reliance on gossip callback ordering. Gossip does
  not guarantee that version updates arrive in-order, and we currently
  persist the cluster version blindly. *ExposedClusterVersion would
  have to do its own synthesis to refuse illegal changes backwards. This
  may be a non-issue but needs some consideration (all of the cluster
  settings would be vulnerable to it).
• gossip more. We currently gossip ServerVersion but really you care more about the version the server is operating at (i.e. ServerVersion will be 1.1 even if the binary is still running in compat mode for 1.0).

RFC: #16977

[tbg]

I'll call this done, but we could do more.
Filed #18058 which covers the last item.
Also filed #18060 about ui warnings.

I have not been able to confuse the gossip callback ordering, so I think that's more of a theoretical concern. The worry here is

1. node receives bump to 1.0-2
2. fires goroutine with callback
3. node receives bump to 1.0-3
4. fires goroutine with callback
5. second callback executes
6. first callback executes

in this case, the version statemachine would see two bumps that are each illegal. I can't promise it, but I definitely suspect that it would panic the server. If it doesn't, that's almost as bad because the server likely won't operate at the desired version (1.0-3).