Modify variable_set() / variable_get() to use the config system

I gave this a stab. Problems unfortunately ensued rather quickly. First of all the problem was that I got a fatal error because db_query wasn't defined. I never completely understood how that could happen since we're in the same file as that function is defined.
However, the problem happens when some variables are needed very early, such as the cache_backends.
Normally they are taken from the settings file, and I guess then statically cached, meaning that during a normal bootstrap some vars are available before the db-layer is.

fabsor floated the idea that we could create a static config-class, and pass that one instead of DrupalVerifiedStorageSQL to DrupalConfig during the earliest bootstrap phases.

See also #1175054: Add a storage (API) for persistent non-configuration state.

Just a potential solution: create all kinds of storage such as:
DrupalConfigStorageEnvironment (fetches env. variables)
DrupalConfigStorageArray (get data from an array)
DrupalConfigStorageInfo (read and parse an info file, quite fast)

Then use one, two, or the three in override order env -> array -> info per default.
Gives a lot of places to put pre-bootstrap conf.

I'm claiming this one for now, me and Letharion are going to work together on this in a very near future.

I spent a day trying to get this to work and while I got quite far, I think the best thing to do is just to skip the variable_get/set "backwards compatibility" altogether and just keep on working on getting more and more parts of core converted to the new system.

So what I did to try and get this working was that I created a new kind of VerifiedStorage, DrupalVerifiedStorageMemory. This implementation of DrupalVerifiedStorage did not do any persistent storage at all, and was basicly just a wrapper around an array. This worked, but what I realized was that the actual storage was never even used since, everything was stored in the actual config object. This of course means the whole idea was stupid, but it opened some doors, since I could actually change the loading of the configuration from settings.php to use the same config system as the rest of Drupal uses, which is a big win.

* I moved things around a bit in config.inc, and added an alternative function for creating a config object, bootstrap_config. I did this since we haven't really figured out how we want to load different configs yet.

* I changed the _drupal_settings_initialize function quite a bit; I changed the $conf array so that it was an instance of the config object, that config object was tied to it's own bin, core.base. I did this since I realized that we probably don't want to mix things that needs to be set in the early bootstrap (everything defined in settings.php) with things that we set in the UI and is used after doing a full bootstrap, or at least after bootstrapping the db. I then passed the config object into settings.php, which automaticly means that settings.php is adding things on top of config object available through the same config system as everything else.

* I changed the variable_get/set/del so that it used the config system in the bin core.variable. I also added some safeties in the variable_get function so that it fetched stuff from core.base (which basicly stored everything from settings.php) if the bootstrap phase was lower that BOOTSTRAP_DATABASE. This meant that any call to variable_get/set/del was using the config system. This also meant that we could remove variable_initialize and all the custom caching stuff we were doing for the variable table, since that would be fixed by the actual VerifiedStorage engine we were using.

These changes got me to the point that we could ge to do the bootstrap_full stuff. That's were we got all hanged up, since I realized that the variable system we have now allows uses serialized PHP values, which does not translate very well into XML. Attached to this post is a sample core.variable.xml file that illustrates how it looks.

My conclusion: We should not try and just replace the variable_get/set system as is, because it is far too non-specific and it allows for an arbitrary storage that we simply can't match with our current XML formats. I think we will get more out of trying to attack each part of core, maybe starting at getting a good system for exposing the early configuration things in bootstrap.

One thing that we might want to introduce is some kind of configuration object that is just read-only. We won't be able to write to the settings.php file, but I still think we need something like that to be able to do things like connecting to the database and for instance select our default VerifiedStorage engine.

I'm posting a patch of the things I played around with here just for reference. A lot of the things are quite ugly, because I just wanted to get as far as possible in the first step, but I think it could be a good thing to have just as part of the "documentation".

Does you patch allows configuration to be overriden by hardcoded values in settings.php file? That's a feature that core actually supports and that really is useful. Any environment provided variable override would be a plus too.

Your code checks upon the bootstrap state of core, and uses the "core.variable" bin only if database bootstrapped, so these are settings.php provided variables that will disappear once the database has boostrapped, doesn't it sound odd to you that we may have early variables that will change arbitrary during runtime?

Is this able to keep both data from "core.base" and "core.variable" playing together, the first overriding the later to ensure that hardcoded overrides remains?

This seems to be obsolete by now.