Fix NoPreExistingSchemaUpdateTest when MINIMUM_SUPPORTED_PHP is used

#3265412: QuickStartTestBase is incompatible with the current implementation of MINIMUM_SUPPORTED_PHP causes the remaining out-of-scope failures.

@daffie, sorry, I forgot that MRs and/or alternate environment tests don't automatically set issues NW for failures. This was just a bit of TDD. I've been debugging locally and the browser output makes it appear that either HEAD is actually broken or the test makes faulty assumptions. Will post more detail later on this and #3265377: Fix LocaleTranslatedSchemaDefinitionTest when MINIMUM_SUPPORTED_PHP is used.

So the test failure is:

1) Drupal\Tests\system\Functional\UpdateSystem\NoPreExistingSchemaUpdateTest::testNoPreExistingSchema
Behat\Mink\Exception\ResponseTextException: The text "Schema information for module update_test_no_preexisting was missing from the database. You should manually review the module updates and your database to check if any updates have been skipped up to, and including, update_test_no_preexisting_update_8001()." was not found anywhere in the text of the current page.

/var/www/html/vendor/behat/mink/src/WebAssert.php:785
/var/www/html/vendor/behat/mink/src/WebAssert.php:262
/var/www/html/core/tests/Drupal/Tests/WebAssert.php:898
/var/www/html/core/modules/system/tests/src/Functional/UpdateSystem/NoPreExistingSchemaUpdateTest.php:73
/var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:703

ERRORS!
Tests: 1, Assertions: 10, Errors: 1.

The thing about this test is that it is already using $this->updateRequirementsProblem() correctly:

    $this->drupalGet($update_url);
    $this->updateRequirementsProblem();

    $schema = \Drupal::service('update.update_hook_registry')->getAllInstalledVersions();
    $this->assertArrayHasKey('update_test_no_preexisting', $schema);
    $this->assertEquals('8001', $schema['update_test_no_preexisting']);
    // The schema version has been fixed, but the update was never run.         
    $this->assertFalse(\Drupal::state()->get('update_test_no_preexisting_update_8001', FALSE));
    $this->assertSession()->pageTextContains('Schema information for module update_test_no_preexisting was missing from the database. You should manually review the module updates and your database to check if any updates have been skipped up to, and including, update_test_no_preexisting_update_8001().');

On PHP 7.4

This is what the HTML output from the test is supposed to look like, on PHP 7.4:

On PHP 7.3

When the test is run on PHP 7.3, there are two screens instead of one, from successfully clicking past the warning:

Note that the text from the final assertion is shown on the first page, with the PHP warning, instead of the second. So this is sort of an actual bug in core.

We could just change the test so that the assertion is called earlier, when it will pass regardless of whether the PHP is below the supported minimum or not, as is done in 3265378-move-assertion. However, I'm not sure that's the correct fix because the message about the schema information makes more sense in the context of the main update.php screen. If it's presented on the warnings screen, there's too much different information for the site owner to address at once.

The message is added at the end of _update_fix_missing_schema(), which in turn is called from update_check_requirements():

function update_check_requirements() {

  // Because this is one of the earliest points in the update process,
  // detect and fix missing schema versions for modules here to ensure
  // it runs on all update code paths.
  _update_fix_missing_schema();

  // Check requirements of all loaded modules.
  $requirements = \Drupal::moduleHandler()
    ->invokeAll('requirements', [
    'update',
  ]);
  $requirements += update_system_schema_requirements();
  return $requirements;
}

Because the message is added before the requirements warnings are handled, this means it shows up on the warnings screen, rather than the main database update page.

To fix this, we'd have to additionally add some custom code in DbUpdateController::handle() to check whether the message is loaded, save it, unset it, and reset it after the requirements warning happens...

Or, to avoid some of that we could move the logic directly into DbUpdateController::handle(), which would allow us to check for the problematic condition early, but then raise the message later after the warning handling. I'll try to code that up.

3265378-move-messages implements #11, by moving the messages to state when there are warnings and fetching them from state when the user has clicked past the warnings.

On PHP 7.3, the message is no longer displayed on the warnings page:

Instead, it is moved to the correct screen:

So the question is whether to make that change, which means more code paths to clean up later in the handler when #3130037: system.schema information gets out of sync with module list is fixed, or just to live with the message being on the wrong page and change the test.

OTOH maybe displaying the warning on the first screen is correct, in case they never click past the warning? update.php has already attempted to fix the schema at the start, so something has changed and maybe we should inform the site owner then.

Not sure which approach is best. Updating the IS with both.