Requests for comment/Configuration database 2

Introduction
This is a RfC for MediaWiki to have a sane and easy to use configuration interface through the wiki itself. This RfC is based off a previous RfC and the Configure extension.

Why?
Many of the various MediaWiki settings should be adjustable by local administrators/bureaucrats without requiring sysadmin intervention. Additionally, this would make those configuration values public to all users without requiring the LocalSettings.php file being uploaded somewhere.

Requirements

 * Performant: should not slow down the site
 * Backwards compatible: should work fine with existing code and extensions
 * Farm support: Work for both single-wiki installations and large farms like Wikimedia
 * Cross-wiki support: should be able to access another wiki's settings
 * Flexible permissions system

Storage
Settings are stored in a "LocalSettings.json" file. It uses a simple key storage method. If performance becomes an issue, the backend is abstracted so a format like CDB could also be used. In the future, this could also use a DataStore backend.

You might ask why not use a custom ContentHandler? There are security issues with storing private information in page text, and it would be difficult to access another wiki's settings.

Metadata
DefaultSettings.php will become a huge array of metadata, similar to how the Configure extension works.

An example might look like:

A hook will be available to extensions to add their own configuration options.

Accessing settings

 * For backwards compatibility, all globals will still be accessible.
 * Something similar to SiteConfiguration::extractAllGlobals will be called
 * Accessible via context:

Internal interface
Get a Conf object via context:

Basic variable lookup:
 * (shortcut)

If you wanted to lookup another wiki's settings:

Backwards compatibility

 * Something similar to SiteConfiguration::extractAllGlobals will be called so globals will still work
 * If a LocalSettings.php file is detected, it will be loaded:
 * Loading order will be: DefaultSettings.php, LocalSettings.php, and then LocalSettings.json
 * A maintenance script could be written to migrate LocalSettings.php files to a LocalSettings.json file.

Code mockup
Just a rough implementation, not even close to complete

Special page

 * New special page at Special:ConfigureSettings. It will look similar to Special:Preferences, and uses HTMLForm.
 * The page is based on categories, so if you want to edit something in the "site" category, you would go to Special:ConfigureSettings/site. For SpamBlacklist, it would be Special:ConfigureSettings/SpamBlacklist.
 * The main Special:ConfigureSettings is just a landing page with a listing of various categories.
 * If users cannot edit certain fields because they do not have the proper rights, they can still view the current value (unless it's set to private).

User rights

 * There is one super powerful right named 'configure' which lets you view and configure everything
 * Each category by default checks for 'configure-$name', unless there is a 'right' key set. If a variable in this category uses a more specific right, it is not automatically inherited.
 * Each right checks for 'configure-$wgName', unless there is a 'right' key set.

Logging

 * This will use the standard MediaWiki logging mechanism.
 * Entries will look like "Tim changed $wgMagicEnabled from false to true (happiness for everyone!)".
 * If a variable is set to private, the log entry will only say: "Tim changed $wgMagicEnabled".