SHOR-9: Fix regression issues advanced search

Merge pull request #12438 from totten/master-contact-sel

(dev/core#217) CRM_Contact_Selector::getRows() - Use generator instead of DAO loop

Merge pull request #12441 from totten/master-sql-del

Implement CRM_Utils_SQL_Delete

Implement CRM_Utils_SQL_Delete

Before
------
* `CRM_Utils_SQL_Select` and `CRM_Utils_SQL_Insert` are query-building utilities.

After
-----
* `CRM_Utils_SQL_Select`, `CRM_Utils_SQL_Insert`, and `CRM_Utils_SQL_Delete` are query-building utilities.
* `CRM_Utils_SQL_Select` and `CRM_Utils_SQL_Delete` extend a common base-class, which includes parameter-management/interpolation functions.
    * (*Note: Initially tried doing this as a trait, but traits aren't allowed to define constants.*)

(dev/core#217) CRM_Contact_Selector::getRows() - Use generator instead of DAO loop

Currently, cached data is read from MySQL, so it's OK to treat `$result` as
DAO.  However, eventually, we'll cache in a different data-source, and (when
dealing with multiple backend) it'll be easier to support a
`Generator<Object>` rather than `CRM_Core_DAO`.

See also: http://php.net/manual/en/language.generators.overview.php

(dev/core#217) CRM_Core_DAO - Add a helper which returns results in generator format

Merge pull request #12430 from JMAConsulting/dev-core-239

dev/core#239 : Fix title dialog box on hovering form element on Event's configuration backend form

Merge pull request #12422 from JMAConsulting/dev-core-176

dev/core#176 Odd / Even street number sort column missing from Reports

Merge pull request #12429 from eileenmcnaughton/comment

[NFC] Update comment link

dev/core#239 : Huge title dialog box on hovering form element on Event's configuration backend form

Update code link

Merge pull request #12427 from totten/5.4-sqlgroup-ttl-1

(dev/core#174) CRM_Utils_Cache_SqlGroup - Refine trivial TTL handling to stabilize tests

Merge pull request #12428 from civicrm/5.4

5.4

Merge pull request #12417 from aydun/core_124_template_upgrade

Follow up to PR 12160 to update the DB version of the templates

Merge pull request #12426 from totten/master-container-cache

Change default for CIVICRM_CONTAINER_CACHE to simplify admin/developer experience

Merge pull request #12425 from seamuslee001/5_3_alpha1_fix

Ensure db updates are run for 5.3.alpha1

(dev/core#174) CRM_Utils_Cache_SqlGroup - Refine trivial TTL handling to stabilize tests

Since incorporting `E2E_Cache_SqlGroupTest`, we've observed periodic flakiness in some
of the test-runs around code like this:

```php
  $cache->set("key", "value", 1);
  $get = $cache->get("key");
```

This makes the tests more reliable by refining the way `SqlGroup` handles trivially short TTLs.

Before
----------------------------------------
Cache items with `$ttl=1` may be expired before you ever get a chance to read them.

After
----------------------------------------
Cache items with `$ttl=1` may sometimes last slightly longer than a second
(if recorded late in the clock's current second), which improves the odds that
you'll be able to read the cache.

Technical Details
----------------------------------------
To reproduce the problem, run this script a few times via `cv scr`:

```php
<?php
$cache = CRM_Utils_Cache::create([
  'name' => 'tmp-cache',
  'type' => ['SqlGroup']
]);

for ($i = 0; $i < 500; $i++) {
  $cache->set("foo_$i", 'hi', 1);
  $get = $cache->get("foo_$i");
  if ($get !== 'hi') {
    echo "miss! ($i)\n";
  } else {
    echo ".";
  }
}
```

Given that `$cache->set()` and `$cache->get()` are right next to each other,
you would expect (and the test authors did evidently expect) that cache would be valid
long enough to read content. And yet we periodically have a cache-miss (particularly with
`SqlGroup`, which is a bit slower to handle writes).

For example, suppose `microtime()===100.95`.  If you compute expiration as
`$expires=time()+$ttl`, then `$expires===101`.  However, this means that
the cache's effective validity period is more like `~0.05` seconds rather
than a full second.

A more correct solution would be to track expiration times as microseconds.
However, that's a bigger patch, and we don't really need that level of
precision -- typical TTLs for us are more like "a week" or "a day" or "an
hour" or *maybe* "a minute".  The `$ttl=1` is a trivial scenario that only
makes sense for unit-testing.

This patch just rounds up the calculation of `$expires` -- in our
hypothetical at `microtime()===100.95`, that makes `$expires===102` and an
effective validity period of `~1.05` seconds.

Merge pull request #12412 from eileenmcnaughton/conformance

Enable syntaxConformance on entities that now succeed

Merge pull request #12406 from jitendrapurohit/core-212

dev/core#212 - Contribution Details report fails when 'Is not one of'…

Merge pull request #12414 from eileenmcnaughton/option_value

Simplify input params on OptionValue::addOptionValue

Change default for CIVICRM_CONTAINER_CACHE to simplify admin/developer experience

In discussion of cache-related PRs for Civi 5.3, there were a few
reports/issues from developers observing `ServiceNotFoundException`.  This
is because there's not much awareness about how service-definitions are
cached.  It shouldn't be a significant issue for production systems running
vanilla code, but for admins and developers (who juggle patches/branches),
it can cause confusion/support-issues/false-failures.  This PR aims to
reduce those.

(This is a follow-up/substitute for #12401.)

Before
------
* The default value of `CIVICRM_CONTAINER_CACHE` is `always`.

After
-----
* The default value of `CIVICRM_CONTAINER_CACHE` is `auto`.

Technical Details
-----------------
The Symfony container essentially stores a list of "services".  In some
Symfony-based apps, building the list of services can be time consuming, so
it's common to cache this.

In Civi, this cache physically appears as
`files/civicrm/templates_c/CachedCiviContainer.*.php`.  The constant
`CIVICRM_CONTAINER_CACHE` determines how Civi manages the cache.  There are
three available policies:

* `never`: This means we never use the cache.  You never have to worry about
  staleness.  But it means we have to fire `hook_civicrm_container` on every
  page-request, and we go through any container-compilation tasks.
  This would have the fewest support-issues for devs and advanced admins.

* `always`: This means we always use whatever is in the cache.  It never
  (automatically) rebuilds the cache or checks freshness...  if you make
  change, then you must flush the cache explicitly.  This should be the
  fastest in production.

* `auto`: This means we typically use the cache (avoiding
  hooks/recompilation), but it has to `stat()` a half-dozen files to check
  the modification time.  (To wit: if the timestamp on
  `Civi/Core/Container.php` changes, then we discard the cache.)

Since performance is a consideration, I did some light benchmarking on my
laptop (fetching a basic public Civi page 100 times across 3 threads).

https://gist.github.com/totten/ec4bffd723afb7967aec56a3040b9ca3

In these results, the `never` policy appears to be ~15-20ms slower than
`auto` or `always`. `auto` is only ~2ms slower than `always`.

The other consideration is accuracy -- `auto` will usually re-compile if you
make a change, but there are some edge-cases where you must still flush
manually.  (In particular -- when you first implement
`hook_civicrm_container` in a new extension, it might not be aware of the
new extension.  And extensions need to call `$container->addResource()`.)

However, overall, `auto` is a pretty good compromise that's almost as fast
you can get and works out-of-the-box for many dev/admin scenarios.

Ensure db updates are run for 5.3.alpha1

Merge pull request #12418 from eileenmcnaughton/totten

CRM_Core_BAO_PrevNextCache - Remove unused buildSelectedContactPager()

dev/core#212 - Contribution Details report fails when 'Is not one of' condition is used for Groups field

dev/core#176 Odd / Even street number filter missing from Reports

CRM_Core_BAO_PrevNextCache - Remove unused buildSelectedContactPager()

This does not appear to be used anywhere (based on grepping universe).

Follow up to PR 12160 to update the DB version of the templates

Enable syntaxConformance on entities that now succeed

Set version to 5.5.alpha1

Set version to 5.4.beta1

Merge pull request #11998 from compucorp/PCHR-3410-add-default-assignee-when-creating-cases

dev/core#107: Add default assignee when creating cases

dev/core#107 Refactor selection of default assignee by relationship type

dev/core#107 Automatically add default assignees when creating new cases

This feature allows users to define default assignees for each activity in a case type.
When creating a new case contacts are assigned to activities automatically by following
one of these rules:

* By relationship to case client
* The user creating the case
* A specific contact
* None (default)

Simplify input params on OptionValue::addOptionValue

The addOptionValue function is one we should probably deprecate/ remove but towards that we should
start to remove it. This commit removes some complexity by passing option_group_name rather than
groupParams - which is a more accurate reflection of usage and removes ambiguity around the passing
by reference

Merge pull request #12411 from eileenmcnaughton/matt_opt

Fix sample custom data is_reserved=0

Merge pull request #12403 from civicrm/5.3

5.3

Merge pull request #12409 from eileenmcnaughton/paydata

dev/core/issues/211 Fix mis-allocation of financial transactions when editing payment method on a completed payment

Add late changes

Fix mis-allocation of financial transactions

Per

https://lab.civicrm.org/dev/core/issues/211 there seems to be an issue with assigning entity_financial_trxn
entries the wrong financial_trxn_id - I cannot find any recent change that would have caused this
(unless it's simply the greater use of the payment edit block) - it has been reported as working in
5.0.2.

Fix sample custom data is_reserved=0

Merge pull request #12233 from mattwire/optiongroup_form

dev/core#155 Improve Option Groups form

Merge pull request #12296 from eileenmcnaughton/greeting

Use email_greeting where possible in receipts

Merge pull request #12408 from eileenmcnaughton/location_id

Add location_id if missing CRM-20711.

Merge pull request #12399 from eileenmcnaughton/jamie

dev/core/#/229 Fix fatal error on send test mail

Add location_id if missing CRM-20711.

On a small number of installs it seems location_id is missing from the group_contact table. This adds if missing

Merge pull request #12398 from agh1/5.3.0-releasenotes

5.3.0 release notes

Merge pull request #12362 from totten/master-cache-session

(dev/core#174) Forms/Sessions - Store state via Civi::cache('session')

Merge pull request #12391 from eileenmcnaughton/matt

Revert change to BillingBlock to support hidden fields.

Fix fatal error on send test mail

Merge pull request #12400 from seamuslee001/dev_core_227

dev/core#227 Fix issue where on some extened groups the multiple reco…

Merge pull request #12394 from yashodha/dev-223

(dev/core#223) Expose prefix and suffix in reports

Add release notes for 5.2.2

Add release notes for 5.2.1

5.3.0 release notes: combined, organized, added contributors, boilerplate

Also removed redundant issues from 5.2.1 and 5.2.2

5.3.0 release notes: my half of the issues

5.3.0 release notes: Alice part of release notes

dev/core#227 Fix issue where on some extened groups the multiple records checkbox doesn't show this causes empty string to be passed in which was causing problems when working out if we needed to make changes to the custom value table

Merge pull request #12393 from scardinius/core-222

dev/core#222 - Fix importing contacts with dedupe rule

Merge pull request #12389 from totten/master-psr16-xtest

(dev/core#174) Add test to prevent hidden interactions among caches

5.3.0 release notes: raw from script

(dev/core#223) Expose prefix and suffix in reports

Merge pull request #12340 from eileenmcnaughton/merge_cleanup

Move DAO function to DAO class, call it from Merge class

dev/core#222 - Fix importing contacts with dedupe rule

Merge pull request #12390 from yashodha/dev-220

(dev/core#220) State province/country doesn't show properly in the…

Revert change to BillingBlock to support hidden fields.

Per discussion with Matt Wire this is actually unnecessary, if we define 'id' in the payment fields
metadata. This is a bit too much like spooky magic but it ... erm .. works

core/issues#220 - State province/country doesn't show properly in the history report

(dev/core#174) Forms/Sessions - Clear in roughly the same ways as before

In the past, if one clears the `civicrm_cache` table (i.e.  by calling
`CRM_Core_Config::clearDBCache()` ==> `TRUNCATE TABLE civicrm_cache`), then it
has the effect of destroying any active sessions/forms.

Now, in allowing sessions to be stored elsewhere, we lose that side-effect.

If we want strictly equivalent behavior (from a business-logic perspective),
then we'd want the patch to go a bit further -- calling
Civi::cache('session')->clear() at the same time that it does
`clearDBCache()`.

This revision adds `clear()` calls to various spots discussed here:

* https://docs.google.com/spreadsheets/d/1FxuIvr2noelBvhu5eja9_ps3YUWnkmGhqijBO3gH8Po/edit?usp=sharing
* https://github.com/civicrm/civicrm-core/pull/12362#issuecomment-400897782

(dev/core#174) Forms/Sessions - Store state via Civi::cache('session')

Overview
----------------------------------------

When using forms based on CiviQuickForm (specifically `CRM_Core_Controller`), `CRM_Core_Session`
stores form-state via `CRM_Core_BAO_Cache::storeSessionToCache` and `::restoreSessionFromCache`,
which in turn calls `CRM_Core_BAO_Cache::setItem()` and `::getItem()`.

However, using `CRM_Core_BAO_Cache::setItem()` and `::getItem()` means that all session state
**must** be written to MySQL.  For dev/core#174, we seek the **option** to store via
Redis/Memcache.

Before
----------------------------------------

* (a) Form/session state is always stored via `CRM_Core_BAO_Cache::setItem()` and `civicrm_cache` table.
* (b) To ensure that old sessions are periodically purged, there is special purpose logic that accesses `civicrm_cache`
  (roughly `delete where group_name=Sessions and  created_date < now()-ttl`).
* (c) On Memcache/Redis-enabled systems, the cache server functions as an extra tier. The DB provides canonical storage for form/session state.

After
----------------------------------------

* (a) Form/session state is stored via `CRM_Utils_CacheInterface`.
    * On a typical server, this defaults to `CRM_Utils_Cache_SqlGroup` and `civicrm_cache` table.
* (b) To ensure that old sessions are periodically purged, the call to `CRM_Utils_CacheInterface::set()` specifies a TTL.
    * It is the responsibility of the cache driver to handle TTLs. With #12360, TTL's are supported in `ArrayCache`, `SqlGroup`, and `Redis`.
* (c) On Memcache/Redis-enabled systems, the cache server provides canonical storage for form/session state.

(dev/core#174) Add test to prevent hidden interactions among caches

Merge pull request #12379 from totten/master-psr16-sqlgroup

(dev/core#174) Full PSR-16 compliance for SqlGroup

Merge pull request #12386 from mattwire/IPN_NFC

NFC code cleanup for AuthNet, Paypal, PaypalPro IPNs

Merge pull request #12305 from eileenmcnaughton/dedupe_limit

Re-instate Dedupe limit functionality & fix select toggle functionality

NFC code cleanup for AuthNet, Paypal, PaypalPro IPNs

Merge pull request #12345 from MiyaNoctem/CRM-195-add-counts-to-contribution-sub-tabs

dev/core#195 Add Contribution Counts to Sub-tabs

Merge pull request #12383 from civicrm/5.3

5.3 to master

Merge pull request #12382 from eileenmcnaughton/jaap

Fix mis-reporting of false booleans in reports

Fix mis-reporting of false booleans in reports

dev/financial/issues/24, Add unit test for Link payment method to financial account when created using api (#12365)

* Added api test to create new payment method

* updated api test

Merge pull request #12356 from pradpnayak/issue-202

dev/core/issues/202, check if default currency is set

Merge pull request #12381 from totten/master-psr16-apc

(dev/core#174) APCcache - Updates to comply with PSR-16

Merge pull request #12380 from totten/master-psr16-memcache

(dev/core#174) Memcache(d) - Updates to comply with PSR-16

Merge pull request #12378 from eileenmcnaughton/totten

(dev/core#174) Full PSR-16 compliance for ArrayCache, Redis

(dev/core#174) APCcache - Updates to comply with PSR-16

One noteable quirk is that APC retains expired (per TTL) records until the
following page-request. To comply with the test suite, we have to double-check
the expiration time.

(dev/core#174) Memcache(d) - Updates to comply with PSR-16

There are two drivers, `CRM_Utils_Memcache` and `CRM_Utils_Memcached`.  It's
nice to update them in tandem (with similar design decisions).  If an admin
admin is experimenting/debugging, this consistency makes it easier to switch
between drivers.  (Cache data written by one driver can be read by the other
driver.)

In addition to the standard PSR-16-style changes, there are a couple changes
in how data is formatted when written to memcache:

* To allow support for targetted `flush()`ing (one prefix at a time), we update
  the naming convention per https://github.com/memcached/memcached/wiki/ProgrammingTricks#deleting-by-namespace
  This means that a typical key includes a bucket-revision code:
    * BEFORE: `<site-prefix>/<bucket-prefix>/<item-key>` (`dmaster/default/mykey`)
    * AFTER: `<site-prefix>/<bucket-prefix>/<bucket-revision>/<item-key>` (`dmaster/default/5b33011fea555/mykey`)
* Values are `serialize()`d. This resolves an ambiguity where `Memcache::get()`
  does not let us know if it returns `FALSE` because there's an error because
  that's the stored value. By serializing, those scenarios can be distinguished.
    * `get(...) === FALSE` means "item was not found"
    * `get(...) === serialize(FALSE)` means "item was found with value FALSE"

(dev/core#174) CRM_Core_BAO_Cache - Periodically flush expired records

(dev/core#174) SqlGroup - Rewrite with PSR-16 and TTL support. Bypass BAO multitier cache.

(dev/core#174) Redis - Updates to comply with PSR-16

(dev/core#174) ArrayCache - Updates to comply with PSR-16

Merge pull request #12236 from agileware/CIVICRM-874

CiviCase, added reference of activities from different timelines.

Merge pull request #12376 from totten/master-psr16-util

(dev/core#174) Add various utilities to support PSR-16

(dev/core#174) NaiveMultipleTrait - Fix validation of oddball iterables

(dev/core#174) CRM_Utils_Date - Add helpers for handling PSR-16 TTL's

(dev/core#174) Implement CRM_Utils_Cache::assertValidKey

(dev/core#174) NaiveMultipleTrait - Throw errors for bad inputs

(dev/core#174) Add E2E_Cache_CacheTestCase

(dev/core#174) Add concrete classes for cache exceptions

PSR-16 specifies cache exceptions using interfaces.  This requires that we
implement the interfaces.

Merge pull request #12368 from totten/master-cache-schema

(dev/core#174) civicrm_cache - Finish transition from DATETIME to TIMESTAMP

Merge pull request #12374 from yashodha/report-fixes

core/issues#96 - Expose source column in booking report

core/issues#96 - Expose source column in booking report

Merge pull request #12342 from totten/master-psr16-min

Caching - Comply with PSR-16 interfaces