check if schema version has changed against the old version

[i-just]

Description

A rough outline of what’s going on:

This will happen if src/services/ProjectConfig->areChangesPending(true) in the src/console/controllers/MigrateController->runAction() returns true, in which case we “allow project config changes, but don’t overwrite the pending changes”. When testing I had both devMode and allowAdminChanges set to false.

In the above case:

• the migrate/all --no-content goes through fine until EVENT_AFTER_REQUEST gets triggered;
• that then makes the ProjectConfig->flush() get triggered (it can be enqueued by, e.g. ProjectConfig->set() which calls ProjectConfig->_saveConfigAfterRequest()).
• flush() calls writeYamlFiles(), which writes to files the config we got from getCurrentWorkingConfig(), which at the end of migrate/all can still have “old” version and schemaVersion values

Current working config can still have the “old” schemaVersion value because of those lines (and those for the plugins).

(In terms of 4 to 5 upgrade, the first thing that calls src/services/ProjectConfig->set() is craft/migrations/m230524_220029_global_entry_types->safeUp().
With 5.5.x to 5.6.x, there’s the src/migrations/m241125_122914_add_viewUsers_permission that also adjusts the project config.)

Steps to reproduce

(php 8.2; mysql 8.0)

1. set up a fresh install with just Craft CMS v5.5.10; set devMode and allowAdminChanges to true; ensure you're on a Pro version;
2. create a user group (group1) with permission to access the control panel and to edit users
3. take a backup of the database
4. change the cms requirement to 5.6.4 & run composer update
5. run ddev php craft migrate/all --no-content
6. at this point, all works as expected
7. run ddev php craft project-config/touch
8. make a copy of the config/project folder
9. set devMode and allowAdminChanges to false
10. import database backup (one with version 5.5.10)
11. run ddev php craft migrate/all --no-content
12. after the command has finished, view the contents of config/project/project.yaml - the system.schemaVersion will be set to 5.5.0.0, and it should be 5.6.0.2

Now you can use steps 8-12 to keep reproducing this over and over

Related issues

#16086

[brandonkelly]

Thanks! I was able to resolve the main issue just by preventing migrate commands from writing out their project config changes when there are pending YAML changes. (653c9c1)

The changes in this PR are probably worth doing as well, though, just to simplify the code.