Create and run dependency regression tests for core

Problem/Motivation

We need a testing trigger that re-tests a specified environment when any upstream dependency changes, and we should change our build process to ignore core's lock file and instead test with minimum declared dependencies, as well as testing with the maximum dependencies available when they change.

This would allow us to automatically detect issues with upstream dependency minor/patch level updates while also eliminating the need for a lock file in core at all as we could assure end users that the values in the composer.json were tested with core.

Additionally this would allow us to configure our contrib testing to treat drupal core as a dependency and only re-test contrib when upstream core changes, and not simply 'daily', thus saving on many tests when there are lulls in core activity.

Proposed resolution

First: The trigger.

This check would occur if Composer-based dependencies have been changed. How do we determine if they have changed? If the goal is to double-check the version constraints present in the composer.json, then we have to use that. Since core's composer.json merges other composer.json files, we'd have to check the merged files as well.

We shouldn't use the composer.lock file because it could change even if the version constraints do not.

Second: The test.

There are a few different degrees of severity or strictness we can apply here.

One is to simply try to update all the composer dependencies (with --prefer-lowest and without) and allow Composer to present a dependency conflict error as a test build fail. This would be a build step that could easily fit into the existing testbot simpletest build.

Another would be to perform the above update, and then also run some tests to get code execution. Unit test suite only would be reasonable. This would allow for different versions to break the build by being incompatible, even though they don't declare their incompatibility in Composer. Implementing this would be somewhat complex because it would require extra steps that depend on each other. This might mean creating a new build type and allowing the D.O UI to specify it.

A third option would be that our assessment plugin would have a 'build Composer min/max' flag. This would cause the assessment phase to make enough copies of itself in the build to specify composer install, composer update, and composer update --prefer-lowest for each copy, and then run all the tests. This would be set up in the codebase phase when we discover whether composer.json has changed. This would be a little bit of a violation of our isolated plugins rule. The benefit of this would be: Relatively easy to implement, no D.O prefs to set up, and very thorough.

Remaining tasks

User interface changes

API changes

Data model changes