Problem/Motivation
When you install a site (from config or the regular installer) - the vast majority of the time is spent rebuilding the container. We rebuild the container during every module install.
This issue is going to experiment with another approach.
Steps to reproduce
Install Drupal.
Proposed resolution
Rebuild the container a single time during ModuleInstaller::install() and adjust install loop accordingly.
Remaining tasks
User interface changes
Tweaks to user facing strings when installing multiple modules via configuration synchronisation.
API changes
New setting core.multi-module-install which sets how many modules be installed in one cycle of ModuleInstaller::install() during site install and configuration install.
Add argument to \Drupal\Core\Config\ConfigInstaller::installDefaultConfig() so that we can install configuration in a modules config/install, config/optional, and other installed modules config/optional directories in separate operations. This is necessary as optional configuration has a lot of soft dependencies. New enum \Drupal\Core\Config\DefaultConfigMode to support this.
Rework \Drupal\Core\Config\ConfigInstaller::checkConfigurationToInstall() and \Drupal\Core\Config\ConfigInstaller::findDefaultConfigWithUnmetDependencies() to work with a list of modules. This has a side effect of fixing an existing bug in the config installer that hook_modules_installed is not called for already installed modules when a module is found that triggers an pre-exisiting configuration exception.
New \Drupal\Core\DrupalKernel::resetContainer() that removes instantiated services from the container. This allows for any service properties that are being used for caching to be refreshed after module install. This has a potential impact for any KernelTestBase test that extends \Drupal\KernelTests\KernelTestBase::register() and adds a synthetic service without marking the service as synthetic.
Data model changes
None
Release notes snippet
TBD
