Restrict changes to `target_release` during an update

[plotnick]

If an update is in flight, we shouldn't allow arbitrary updates to target_release because that could introduce a third version in addition to the current/previous release that the planner will use as of #8024. We might, however, want to allow a minor-version update to, e.g., fix a stuck or broken update.

[davepacheco]

I'd propose that we:

• keep track of the oldest releases that has any software running (we've said we need this in order to report status anyway)
• disallow setting the target system release to any "major" version newer than the next scheduled release (e.g., if running 14.1.0, you can go to 15.0.0 or 15.1.0, but not 16.0.0 -- using terminology from RFD 557).

[sunshowers]

We discussed this in today's update watercooler, in the context of #8401. The code currently assumes that only two generations are in play:

1. The target release (tuf_repo)
2. The one generation immediately prior to that (old_repo)

We decided in the watercooler to not change this in #8401 (or for the Reconfigurator-driven update MVP in general).

There are a few different ways we can restrict updates:

1. Disallow setting the target system release to anything different in the middle of an update. In other words, the target release generation can only be set to N+1 after the update to generation N is complete. With this option, the assumption described above is valid. This option is our determination for the Reconfigurator-driven update MVP.
2. Disallow setting the target system release to a new major release. For example, while updating to 17.0.0, prevent an update to 18.0.0 but allow an update to 17.1.0. In this case, the assumption above will no longer be valid -- old_repo could be some arbitrary number of generations behind tuf_repo.
3. Allow setting the target system release to an arbitrary new version in the middle of an update. For the foreseeable future we'll only support updates one major version back, so we don't see ourselves choosing this option any time soon -- it will add quite a bit of complexity to the system.

The choice to stay with option 1 means that in case of a release where we couldn't finish the update due to a bug, and had to make a new minor release with a bugfix, the recovery path is a MUPdate (RFD 556). Implementing this RFD is a hard blocker for the update MVP anyway, so we aren't imposing any new burdens on ourselves by choosing this option.