Remove ConfigFactory::setOverrideState and ConfigFactory::getOverrideState()

I think this is a clear improvement, removes one moving piece. I think it would be *really* fabulous to document when to use getEditable() on the factory vs. getOriginal() on config vs. getOverrideFree on storage. They are similar in some way (also see some notes below). However I don't think that could be in this patch in some way. Also whole #2392319: Config objects (but not config entities) should by default be immutable's change notice covers some of this, the removal of the public API to switch this state is well worth its own change notice.

1. +++ b/core/lib/Drupal/Core/Config/ConfigFactory.php
   @@ -278,20 +252,17 @@ public function rename($old_name, $new_name) {
   -    $keys = array();
   -    if ($this->useOverrides) {
   -      // Because get() adds overrides both from $GLOBALS and from
   -      // $this->configFactoryOverrides, add cache keys for each.
   -      $keys[] = 'global_overrides';
   -      foreach($this->configFactoryOverrides as $override) {
   -        $keys[] =  $override->getCacheSuffix();
   -      }
   +    // Because get() adds overrides both from $GLOBALS and from
   

   Should this not depend on immutability as well? Correction: ah, you only invoke it if immutable.

2. +++ b/core/modules/config/src/Tests/ConfigCRUDTest.php
   @@ -87,9 +85,7 @@ function testCRUD() {
   -    $config_factory->setOverrideState(FALSE);
   -    $this->assertIdentical($config_factory->get($name)->isNew(), TRUE);
   -    $config_factory->setOverrideState(TRUE);
   +    $this->assertIdentical($config_factory->getEditable($name)->isNew(), TRUE);
   

   Woot, so much better :)

3. +++ b/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php
   @@ -179,7 +186,7 @@ protected function doLoadMultiple(array $ids = NULL) {
   -      $records[$config->get($this->idKey)] = $config->get();
   +      $records[$config->get($this->idKey)] = $this->overrideFree ? $config->getOriginal(NULL, FALSE) : $config->get();
   

   Is this what we expect? Config's get returns the current runtime value (may be different from getOriginal() which is the "on disk" value). So there are subtle differences between override free and original depending on whether there are runtime changes.

@alexpott: ok I don't have a problem with that; I think there are definitely tests where they use the config API direct so the config entity storage cache may not be updated; that evidently does not fail, I guess we don't use the entity API after that. Not sure if we want to add a test for or against what we expect here but if this is an expected behavior it sounds like it would make sense.

Config entities do not have static cache enabled by default at the moment: #1885830: Enable static caching for config entities

I see there are getFromStaticCache and setStaticCache methods but the config entity type is not statically cacheable, so no use. Haha.

Yes they are theoretically, we AFAIK use it for roles, but it is not enabled by default. And if you look at the other issue, the tests there fail with dozens of weird invalid cache issues, that I was too lazy to track down.

But agreed that for those that we do cache statically, we should not cache them twice. Which is more complicated than it sounds I think, maybe the entity storage class could tell the factory to not cache what it is loading, but there is also the entity query implementation that afaik works on raw config values, so that would make entity queries possibly slower.

All right, I did not find anything else. Added draft change notice at https://www.drupal.org/node/2410365

Since catch committed #2392319: Config objects (but not config entities) should by default be immutable and this seems highly related, tossing over to him.

Really like this. It's hard to get your head around config overrides and this removes a potential source of confusion.

Committed/pushed to 8.0.x, thanks!