Inside the migration code for upgrading between releases a system cluster will always bump version numbers
as needed as we go through each step of migration. On the tenant side, these operations are implemented as
no-ops, so there is a potential risk for horrible things to happen if a crash occurs (the same migration logic may
be run twice). Additionally, for certain types of version gating, we need to have the version bumped immediately for example #68074 since a version gate is used to stop certain operations. The current logic for the system tenant updates in memory and on storage values by RPCing out to all pods, which isn't feasible for tenants.

This issue will attempt to address this by always updating the system settings table at each step, and implement the remaining logic by waiting for the change to be visible on pods for the system case.