Make Drupal 8 fast by default: DEV/PROD toggle in settings.php, default to PROD

Updated: Comment #0

Problem/Motivation

Drupal is slow by default.

Proposed resolution

TL;DR: we want Drupal 8 to be fast by default, but we don't want to annoy/slow down developers.

Drupal 8 should be fast by default. Fast by default implies things like page caching and CSS aggregation being enabled out of the box. Which is annoying for developers. So it must be easy to make Drupal developer-friendly. Hence: a DEV/PROD toggle.

This was already being discussed over at #1537198: Add a Production/Development Toggle To Core, but there it involved too much discussion in irrelevant details. The only thing we care about, is to actually have a DEV (developer-friendly) / PROD (fast) toggle and awareness. So this issue focuses solely on that.
Note that I did read that entire issue and incorporated all relevant points here.

It must not be configurable in the UI because then the environment information would be available too late (see #30 & #31 in the other issue).

A selection of frequently mentioned/wanted things that can be done in follow-ups:

1. JS minification (either using .min.js files, built-in JS minification, or something else)
2. Making the Drupal kernel environment-aware. We could do things there to have a more optimized container when in PROD.
3. Ability to configure custom environments. (The simplest thing possible here is only two states; more states is a follow-up/nice-to-have.)
4. Look into making it configurable in the UI, learning from/using authorize.php— see #1537198-37: Add a Production/Development Toggle To Core.

Remaining tasks

TBD

User interface changes

None.

API changes

A new $settings['environment'] setting in settings.php, which defaults to ENVIRONMENT_PROD, but can be set to ENVIRONMENT_DEV.

Background

catch, Alex and I discussed this at DrupalDevDays Szeged. We considered various approaches:

1. An environment change triggers an event. Modules that want to, can react to it, and then override config with developer-friendly values. Downsides: a lot of boilerplate, and we don't know what to set it back to.
2. Environment-specific configuration overrides. Downsides: make the config system more complex, and we don't know what to set it back to.
3. Leverage Symfony's Kernel class's PROD/DEV mechanism. Downsides: requires separate controllers.

The simplest thing, we concluded, is this:

1. Config acts as it does today: it contains the "intended" configuration, for the "intended" site: a PROD site.
2. When in DEV, all modules that are PROD/DEV-aware simply ignore config and go for the developer-friendly option: no page caching, no CSS aggregation …
3. DEV/PROD is stored in settings.php
4. Sites with more complex needs can still override services.