[policy, no patch] Determine Composer validation rules for installing through Composer

Problem/Motivation

#3284945: Install endpoints that leverage Package Manager + core APIs → will expose installing via Composer through the UI
#3245770: Create a service to composer install via package_manager from Automatic Updates → was split out to just handle the package_manager(the sub-module of AutoUpdates) integration

But regardless of the code the rules for Composer operations should be well defined. Asking Composer to require a new package could result in other side effects. Although there will be validation through the UI the installer service should not perform Composer operations that do not follow the rules that will be defined.

Example of possible side effects of requiring a new project

1. Vendor dependencies could be update
2. New vendor dependencies could be added
3. Core could be updated to any version
4. Another Drupal project on site could be updated, this project may or may not have extensions that are currently installed(in the Drupal meaning)
5. Another Drupal project could be installed that is currently not in the code base
6. Custom Drupal projects could be added or updated. these projects would not have drupal.org Update XML
7. Any of the Drupal projects that were updated could have database updates. that will need to be run. This includes core and any enable extensions that are enabled
8. Drupal projects that were update or installed could be on insecure or unsupported versions according to drupal.org's Update XML
9. If the requested project's version is not explicitly set then it could be installed to a insecure or supported version
10. A Drupal project dependency could be updated or installed via Composer but the project may have already been installed on the site just not through Composer.

We should not assume any of these things will not happen based on the Composer command that is run. Package Manager provides a PreApply event where the actual staged packages can be check against the active code base.

Proposed resolution

Side affects Project Browser will allow in the MVP version of Composer installs

Allow all new/updated vendor packages and new/updated Drupal modules and themes.

Only Drupal modules and themes are that secure according to drupal.org Update XML → will be allowed to have there version affected during an update. Only updates and never downgrades to Drupal projects will be allowed. This would mean that Project Browser would responsible for warning the user about database updates and making sure the database updates are run after the update.

Operations that would would conflict with extensions not known to Composer will cause an error. This will forbidden operations if

1. A new project is installed but that project is already in the codebase *anywhere* but is not known to Composer
2. A new project is installed and adds a new dependency that is already in the codebase *anywhere* but is the dependency not known to Composer
3. A new project is installed and updates an existing dependency but is the dependency not known to Composer

All of the conditions would only trigger an error after the Composer operation the is staged. So the user would have to attempt to do the update first and then be notified of the error. This is because we can't fully know what dependencies would be updated or added before operation is executed. The staged composer operation will not affect the active site.

The individual issues needed for the above validation are laid out in #3300309: [Meta] Use Package Manger(From AutoUpdates) API to install via Composer → . This issue is just to get agreement on the above validation/restrictions.

#3284945: Install endpoints that leverage Package Manager + core APIs → should not be committed until validation enforces the desired behavior.

Remaining tasks

Sign-off