Memcache for extension, setting, and string caches

CRM_Core_Config - Simplify. Current cache commands are pointless.

MagicMerge - Changes to properties should not be persistent across requests

Remove CRM_Core_Config_Defaults

MagicMerge - Per-request cache of path/url properties

Civi::paths() - Decouple settings from paths. Allow path vars.

There has been a policy underwhich paths and URLs are assumed to be relative
to different points (urls => webroot; paths => sites/*/files/civicrm).  For
some settings, this is fairly confusing.  The policy had been encoded in
`SettingsBag::getPath` and `SettingsBag::getUrl`.  It's particularly
confusing because (sometimes) the default value of a specific property isn't
really aligned with the policy.

This revision attempts to cleanup in two ways:

 1. It removes policy from `SettingsBag` and puts it in `Civi\Core\Paths`.
 2. It makes the policy less important by allowing variables in the paths.
   * `[civicrm.files]/upload` might evaluate to `/var/www/sites/default/files/civicrm/upload`
   * `[cms.root]/myuploads` might evaluate to `/var/www/myuploads`

The revision also updates MagicMerge to store various path and URL policies
in `getPropertyMap()` rather than adhoc callbacks.

CRM-16373 - rm CRM_Core_Config_Variables

civicrm_navigation.tpl - Move defaults into settings/*.php

For a large number of settings, defaults are declared twice -- once in
`xml/templates/civicrm_navigation.tpl` and once in `settings/*.php`.  In
many cases, these are identical/redundant, but there are a couple where the
defaults diverged.

I believe the `civicrm_navigation.tpl` values have generally taken precedent
on new installations, so this commit revises `settings/*.php` to fix any
discrepancies.

SettingsBag::setDb() - Merge in CRM_Core_BAO_Setting::_setItem and ::dao()

CRM_Core_BAO_Setting - Remove redundant static cache

Before CRM-16373, the setting cache was stored in a static property of the
BAO.  This data is now loaded into objects -- which are stored in the
container.

This is essentially the same for a typical request, and (for unit-testing)
it provides simpler cleanup between tests.

CRM-16373 - SettingsManager - useMandatory() to apply post-boot changes

Note: The global `$civicrm_setting` is meant to provide sysadmins with a way
to override settings in `civicrm.settings.php`, but it has traditionally
been possible for extensions to manipulate `$civicrm_setting` in a hook.  If
you do this, please call `useMandatory()` to tell SettingsManager to re-scan
`$civicrm_setting`.

SettingsBag - Add getDefault(), getMandatory(). Cleanup comments.

settings/ - Add comment about critical/bootstrap settings.

CRM-16373 - Simplify UpdateConfigBackend and doSiteMove()

doSiteMove() has been performing a search-and-replace against data
structures which haven't exist since at least 4.0; it seems quite unlikely
that this works.  Anecdotally, the workflow around this either incomplete or
buggy/broken.  Simplifying this is simply a reflection of the reality that
it doesn't do what it was written to do.

Instead, doSiteMove() now resets to a standard baseline/default.

CRM_Utils_PDF_Utils::pdflib - Remove unused function with quaint data defaults

api_v3_SettingTest - Fix up

CRM_Core_Config - Bind to the settings of the active domain at the moment of setup.

I'm not sure this is actually a good behavior, but it's the old behavior,
and there's a unit-test which checks for it.

Core.settings.php - doNotAttachPDFReceipt - Match previous defaults

config->countryLimit - Don't directly modify array

When using magic method for countryLimit, it's difficult to directly modify
the array.  It's easier to replace the array as a whole.

Settings - Remove special cases for `prefetch` and `config_only`

Remove invalid $config->defaultSymbol

Even in v4.5, this field appears to have been undefined, but it probably
behaved correctly anyway because the undefined value was passed into a
function which didn't need it.

Cleanup `config_only` settings (maxFileSize, doNotAttachPDFReceipt, resCacheCode)

Move BAO_Setting::getSettingSpecification => SettingsMetdata::getMetadata

When this function is in the BAO, it requires that the DAO exist. In a new
installation running GenCode, this can create dependency loop (where
generating code requires ts(), and using ts() requires settings, and using
settings requires that you already have the generated code).

CRM_Core_I18n - Use CRM_Core_Config less

CRM_Utils_Cache::create - Use factory function

Low-level tools like GenCode may run without access to a database. When we
try to use caching in central code, the cache-accesses are prone to
crashing. The problem -- in this environment, we shouldn't even try to use
databse for caching.

`CRM_Utils_Cache::create()` will attempt to create the best cache it can,
depending on what services are available.

CRM_Core_I18n::crm_translate_raw - Don't lookup $config->lcMessages for every string

Accessing `$config` is now be a little slower, and this function accounted
for about half of all calls.

GenCode - More complete env

CRM_Utils_System - Cleanup useFrameworkRelativeBase

CRM-16373 - CRM_Core_Config - Use `Runtime` and `MagicMerge`

Civi\Core\SettingsManager - Don't try to read settings if there's no DB

CRM-16373 - Civi\Core\SettingsManager - Load defaults *after* core bootstrap.

CRM_Extension_System - Make it a little easier to skim.

CRM-16373 - CRM_Core_Config_Variables should be strictly about data

The distribution of variables and functions between `CRM_Core_Config` and
`CRM_Core_Config_Variables` seems pretty random.  In anticipation of
swapping out `CRM_Core_Config_Variables`, make a few changes:

 * Move various functions from `CRM_Core_Config_Variables` to BAOs (`provinceLimit, `countryLimit`, `defaultContactCountry`, `defaultContactCountryName`, `defaultCurrencySymbol`)
 * Put deprecated stubs in `CRM_Core_Config`
 * Move most variables from `CRM_Core_Config` to `CRM_Core_Config_Variables`.

CRM_Core_Config - Fix bugs in path/dir settings

CRM-16373 - Search Settings - Fix dupes (eg contact_reference_options/autocompleteContactReference)

Note:
 * The `autocompleteContactReference` and `autocompleteContactSearch` settings don't seem to be really stored as such.
 * The form includes various hacks which effectively saves these fields in `contact_reference_options` and `contact_autocomplete_options`.
 * At runtime, the application logic checks for `contact_reference_options` and `contact_autocomplete_options`.
 * This situation predates the declarations of `autocompleteContactReference` and `autocompleteContactSearch` in `Search.setting.php`. It seems likely
   that these settings have never been useful.

The fields still have some hacks, but they should be a bit easier to read/trace/grep.

CRM-16373 - Localization - Rearrange load/save logic

 * Declare missing setting `languageLimit`
 * Allow saving admin form -- even when using makeMultilingual, makeSinglelingual, addLanguage, and/or languageLimit
 * Move onChange logic for `lcMessages` from `ConfigSetting::add()` to `onChangeLcMessages()`
 * Move locale init from `ConfigSetting::retrieve()` to `applyLocale()`

CRM-16373 - CRM_Admin_Form_Setting - Generate error instead of saving config fields

CRM-16373 - CRM_Admin_Form_Setting_Search - Don't save through ConfigSetting::add()

CRM-16373 - CRM_Admin_Form_Setting_Date - Don't save through ConfigSetting::add()

CRM-16373 - CRM_Admin_Form_Setting_Misc - Don't save through ConfigSetting::add()

CRM-16373 - Migrate Map/Geocode settings

CRM-16373 - Localization - Save through settings instead of domain

ConfigSetting::fixParams - Remove legacy handling for countryLimit, provinceLimit, defaultContactCountry

This appears to be migration logic for handling a change in the format of
select config fields.  The migration logic appears to originate before v3.0.
Since we're only supporting upgrades from v4.0+, there's no point in keeping
it.

CRM_Core_BAO_ConfigSetting::formatParams - Remove silly function

This function is basically just array_merge().

In theory, there's a side-effect where NULL values in `$values` are unset,
but neither use-case seems to make any use of `$values` afterward, and that
smells like an accidental side-effect anyway.

CRM-16373 - Mailer settings - Remove reliance on CRM_Core_BAO_ConfigSetting::create

CRM-16373, CRM-14349 - Config - Disintermediate localeCustomStrings

localeCustomStrings has a pretty w.e.i.r.d. lifecycle (involving table `civicrm_word_replacements`
and column `civicrm_domain.locale_cusotm_Strings`).  This commit does not unweird it, but the
weirdness no longer involves special-case logic on `CRM_Core_Config*` -- all the weirdness is
concentrated in `CRM_Core_BAO_WordReplacements` and `CRM_Admin_Form_WordReplacements`.

CRM-16373 - Simplify loading of enableComponents

CRM_Core_BAO_Setting::dao() - Don't filter on group, but do save a blank group.

CRM-16373 - Save URLs and paths through settings instead of domain

civicrm_api3_setting_getvalue - Skip $config. Use settings.

(Directory,Url).setting.php - Tweaks

CRM_Core_BAO_Preferences - Remove unused file/class/functions

CRM-16373 - CRM_Core_Config_Defaults - Split setValues() into pieces

The major pieces:
 * `userSystem->getDefaultFileStorage`
 * `userSystem->getCiviSourceStorage`
 * `getCustomFileUploadDir`, `getCustomPhpPathDir`, `getImageUploadDir`, etc

CRM_Utils_Geocode - Read settings instead of config

CRM-16373 - SettingsBag - Add getUrl/getPath/setUrl/setPath

CRM-16373 - CRM_Core_Config - Simplify initialization, esp `templateCompileDir`

Generally, this commit removes some silly 1-line functions, misplaed
functions, duplicated steps, obvious comments, and expired comments.

There is a change in `templateCompileDir`.

The `templateCompileDir` had two different intialization blocks (in
different places), which likely arose from variations in the code-paths used
for memcache systems.  Both routines append a locale and create the dir.

This is redundant, and it unnecessarily forces us to resolve the locale
early during initialization.  But honestly we don't need to append the
locale until much later (when/if Smarty is first used).

There are a few oddballs who use `$config->templateCompileDir` and they may
see a slight change (working with the real templateCompileDir rather than
the locale subdir):

 * The cleanup. If this code causes a change, it will be an improvement:
   instead of cleaning the Smarty cache for one locale, it'll clean the
   entire Smarty cache for all locales.
 * Random temp files. The temp files seem to be transactional in nature
   (tied to the specific invocatoin) and not to the locale.

CRM-16373 - Config - Migrate `userFrameworkUsersTableName` to settings

There was some code to initialize this field on Joomla and WordPress, but it
appears to be pointless -- the value is only used within the Drupal UF.
More generally, this is a good thing - we should use CMS API's rather than
peeking into their schema.

CRM-16373 - Config - Remove `userFrameworkVersion`

This is only very rarely used -- seems silly to look it up on every page
request and to cache it config object.

CRM-16373 - Config - Remove `smartyDir`, `pluginsDir`, and `sqlDir`

CRM-16373 - Config - Remove `componentRegistry`

CRM-16373 - CRM_*_Config - Remove unused component config stuff

This code seems to generate default value for domain.config_backend.
However, the only one which defined any defaults was CiviMail, and that's
now moved over to `settings/`.

CRM-16373 - settings - Declare mailer settings

Conflicts:
settings/Mailing.setting.php

CRM-16373 - Config - Remove `enableComponentIDs`

Note: `enableComponents` is heavily used, but `enableComponentIDs` is only
used once.  Generally, it's much easier to write tests based on names
(`enableComponents`) than IDs (`enableComponentIDs`).

CRM-13244 - Civi\Core\Container - Allow hooks to modify container. Cache it.

Conflicts:
composer.json

CRM_Core_BAO_Setting::getItem() - Fix calls which use deprecated parameters. Fix dedupe_email_default conflict.

For `dedupe_email_default`, the default values in `getItem()` and in
`settings/` disagree.  The default in `settings/` seems better IMHO.

CRM-11743 - Civi::log() - Add short hand for logging

checksum_timeout - Use consistent naming

This was a weird one:

 * The admin form rendered HTML element "checksumTimeout" but saved setting "checksum_timeout", which required workarounds.
 * The runtime code read the setting as "checksum_timeout".
 * The metadata defined setting "checksumTimeout". `prefetch` is enabled, but there's no `config_key` or `legacy_key`.

I believe this means that the runtime and admin form worked (because they
agreed that the name was "checksum_timeout"), but the Setting API would not
work (because it used "checksumTimeout").

This revision standardizes on "checksum_timeout" on the theory that
"checksum_timeout" was the actual value used at runtime. This means:

 * If you had configured the form and had it working correctly, it should
   still work correctly.
 * If you had a script to set "checksumTimeout" via API, then it wasn't
   working before, and it's still not working now.

CRM_Core_BAO_Setting::getItem() - Fix calls which use deprecated parameters

CRM_Core_BAO_Setting::getItem() - Fix calls which use deprecated parameters

CRM_Core_BAO_Setting::getItem() - Fix calls which use deprecated parameters

Civi::settings() - Add short hand for accessing domain settings

\Civi::cache() - Add shorthand for accessing cache.

CRM_Utils_Cache_Interface - Add missing "implements"

\Civi - Use facade instead of Civi\Core\Container::singleton()

\Civi - Add facade accessing system services

Merge pull request #6753 from davecivicrm/CRM-17223

CRM-17223 - fix for cvv2 failure.

Merge pull request #6739 from jitendrapurohit/CRM-17205

CRM-17205 -- Fix for broken Free event registration

Merge pull request #6728 from eileenmcnaughton/CRM-14232-add-setting-for-default-lang

CRM-14232 add setting for default contact language.

Merge pull request #6754 from colemanw/CRM-16555

CRM-16555 - Fix double-processors on backend credit card event form

CRM-14232 add setting for default contact language.

If a contact is created & the preferred_language is not set this
setting can be used to manipulate the default.

Tests!

Conflicts:
settings/Localization.setting.php

CRM-14232 adjust options for default contact language

To reflect bgm suggestions  - add current language & remove long-list of countries

CRM-14232 contact default language setting: don't use null as it has special handling

CRM-16555 - Fix double-processors on backend credit card event form

Comment fix

CRM-17223 - fix for cvv2 failure.

----------------------------------------
* CRM-17223: PayJunction CVV Transactions Fail
  https://issues.civicrm.org/jira/browse/CRM-17223

Merge pull request #6738 from eileenmcnaughton/CRM-17075

CRM-17075 convert membership_type_id field to entity_reference field in search

Merge pull request #6698 from jitendrapurohit/CRM-17169

CRM-17169 - Inconsistent Soft Credit Reporting

Merge pull request #6748 from davidjosephhayes/master

Running the fetch_activities cli task stops with a fatal error when t…

Merge remote-tracking branch 'upstream/4.6' into 4.6-master-2015-09-15-10-14-22

Conflicts:
CRM/Admin/Form/Setting/Localization.php
CRM/Event/BAO/Query.php
CRM/Export/BAO/Export.php
CRM/Financial/Page/AJAX.php
templates/CRM/Event/Form/Registration/Register.tpl
tests/phpunit/CRM/Contribute/BAO/ContributionTest.php
tests/phpunit/api/v3/ContactTest.php
tests/phpunit/api/v3/SyntaxConformanceTest.php

Merge pull request #6727 from eileenmcnaughton/comments

comment fixes

CRM-17075 - Open entityRef automatically

Merge pull request #6741 from eileenmcnaughton/comments-formatting

Comments formatting

remove whitespace at end of line

fix formatting

Merge pull request #6745 from monishdeb/testFailures-master

CRM-16941 test failure fix

Merge pull request #6735 from davecivicrm/CRM-17207

CRM-17207 - Use mailto link on contact summary when outbound email is…

Merge pull request #6744 from seamuslee001/CRM-16584

CRM-16584 Remove line causing fatal error

CRM-16941 test failure fix

----------------------------------------
* CRM-16941: Search Form and api.Get fixes for Contact
  https://issues.civicrm.org/jira/browse/CRM-16941

sql changes

CRM-17169 - Inconsistent Soft Credit Reporting

CRM-16584 Remove line causing fatal error

CRM-17075 switch membership_type_id to use entity reference

This commit also adds generic handling for changing select fields to
entity reference fields with tests to ensure previous smart group
behaviour is respected by handling within the convertFormValues function.

This reverts advanced search domain filtering to ?4.4? 4.5? behaviour which does not assume only that domain's memberships should be searched on.

It make be that domain filtering + allowing an override makes most sense. I did think the pseudoconstant & getoptions use the same
mechanism, but it seems they don't. Really they should both allow the same behaviour & override