Installing from existing config causes massive cache.config population and slow installs

Problem/Motivation

When installing a site from an existing configuration, the number of cached entries written to the cache.config bin becomes extremely large. This causes PHP to spend a significant amount of time iterating over these entries every time \Drupal\Core\Cache\MemoryBackend::invalidateTags() is called (for example, whenever configuration or an entity is saved). This dramatically slows down the installation process.

During installation, core alters cache_factory to use MemoryBackendFactory in \Drupal\Core\Installer\NormalInstallerServiceProvider::register(). However, disabling the config cache entirely results in much faster install times.

Without disabling it, MemoryBackend::invalidateTags() must iterate over tens of thousands of cached entries on every entity save or cache invalidation.
See:
- \Drupal\Core\Entity\EntityBase::postSave()
- \Drupal\Core\Cache\MemoryBackend::invalidateTags()

This problem is especially visible on multilingual sites. The config cache contains each configuration item once per language, because \Drupal\Core\Config\CachedStorage::getCacheKeys() includes the collection as part of the key prefix.
For example:
A site with 2000 configs in config/sync and 24 languages will produce roughly 2000 + (2000 × 24) = 50K cached entries in cache.config during installation.

Steps to reproduce

Either:
- Find a large site with lots of configs and languages that can be installed from existing config
- Or install drupal with minimal profile, add lots of languages (faster with php script)

Then compare install times with and without the provided fix.

Proposed resolution

Remaining tasks

TODO

User interface changes

TODO

Introduced terminology

TODO

API changes

TODO

Data model changes

TODO

Release notes snippet

TODO