Use cached version of payment processor.

I am hitting a slightly obscure bug in Redis that is solved by this change.

Per https://github.com/eileenmcnaughton/nz.co.fuzion.omnipaymultiprocessor/issues/55
we have an issue whereby Omnipay adds the gateway to a variable on class when processing payments.

In some cases this gateway will not serialize into a key under Redis causing a fatal.

However, we don't really need it to - the payment processor that we are aiming to cache is
'as loaded' not 'as used'. The caching of the processors appears to have been removed in
the past because of issues around domains -however, I think we can get
past that by changing the cache key.

Merge pull request #12621 from JKingsnorth/remove-unused-vars-process-parti

Remove unused variables from process_participants job

Merge pull request #12608 from eileenmcnaughton/export_sigs

Stop passing imProviders & phoneTypes - use CRM_Core_PseudoConstant:getLabel

Merge pull request #12026 from michaelmcandrew/pass-mailingJobId-to-hookTokenValues

pass mailingJobId to hook_tokenValues

Remove unused variables

Merge pull request #12618 from colemanw/teenly

Fix teeny typo

Fix teeny typo

Merge pull request #12617 from civicrm/5.5

5.5

Merge pull request #12616 from eileenmcnaughton/report_date

Test fix, update activity report adds a this.month filter by default, accomodate

Test fix, update activity report adds a this.month fiter by default so make dates movable.

I also put time at the end of the day to avoid bounciness on status being overdue

Merge pull request #12595 from eileenmcnaughton/payment_processor_domain

API : Set current domain as a sensible default for payment processor

Merge remote-tracking branch 'origin/5.5'

5.4.0.md - Tweak cache notes

5.4.0 release notes (#12605)

* 5.4.0 release notes: raw from script

* 5.4.0 release notes: added boilerplate

* 5.4.0 release notes: finished documenting changes

* 5.4.0 release notes: updated contributors

Set version to 5.6.alpha1

Set version to 5.5.beta1

Merge pull request #12607 from colemanw/caseDetails

dev/core#289 - Fix links on case dashboard

Merge pull request #12610 from mattwire/recurtab_sort_desc

dev/core/issues/277 Sort recurring contributions by newest first

Merge pull request #12606 from JMAConsulting/custom-value-update

Customvalue ID is ignored

Sort recurring contributions by newest first

Merge pull request #12558 from totten/master-prevnext-misc

(dev/core#217) PrevNext - Allow swapping getPositions (etal) for contact-search

Stop passing imProviders & phoneTypes - use CRM_Core_PseudoConstant::getLabel(

Note this function is called once per export - not per row

Merge pull request #12587 from eileenmcnaughton/header_test

Export - add tests out header output, move phone_type_id to metadata

Merge pull request #12585 from eileenmcnaughton/param_passing

Stdise references to BAO_Query->_fields [nfc]

Fix activity edit link

dev/core#289 - Fix caseId url param

Merge pull request #12553 from pradpnayak/77

dev/core/issues/277, Fixed count to include only live recurring contr…

Merge pull request #12602 from colemanw/checkIfFieldExists

NFC - Deprecate duplicate function

Merge pull request #12604 from tschuettler/296-custom-value-return-field

api - CustomValue::get - add handling for comma separated return fields

Customvalue ID is ignored

Explode return values if it is not already an array.

Add unit tests for CustomValueGet return fields

Stop passing relationQuery object now it is not required

Stdise references to BAO_Query->_fields [nfc]

Merge pull request #12596 from eileenmcnaughton/export_ref

[NFC] Export - don't pass arrays as reference when they are not changed

Merge pull request #12591 from eileenmcnaughton/membership_type

Towards using EntityForm.tpl for Membership type & enabling custom data

Merge pull request #12600 from tschuettler/293-geocoding

Skip check for format method when there is no valid geocoding provider

Stricter validation for checkIfFieldExists

NFC - Deprecate duplicate function

Skip check for format method when there is no valid geocoding provider

Export - don't pass arrays as reference when they are not changed

Move definition of phone_type_id to the xml.

This has the side effect of making it such that it only gets 16 char rather than 255. I thnk this is 'ok' here but there is a separate issue open to increase the varchar for all fields on export

Add tests for header output

Merge pull request #12535 from eileenmcnaughton/export_participant_test

Export Add unit test + minor refactor covering specifiable payment output fields for participant export.

Set current domain as a sensible default for payment processor domain

Merge pull request #12592 from civicrm/5.4

5.4 to master

Merge pull request #12590 from totten/5.4-flushcache

(dev/core#284) System::flushCache - Reproduce legacy cache behavior. Improve test performance.

Remove some fields from the form to rely on EntityTrait

Convert 'name' & 'description' to use the entity Fields format.

Note that doing a partial conversion in the template is just a stepping stone to using the
EntityField template, when lots of fields need conversion / review it allows us to break it up

Simplify converstion of fields, convert 2 more

Define entity data for membership type form

Merge pull request #12589 from seamuslee001/password_size

dev/core#291 Allow for field size to be set for password fields

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

`CRM_Utils_System::flushCache()` calls `CRM_Utils_Cache::singleton()->flush()`.
In `5.3`, this triggered a cascading effect; in development of `5.4.alpha`,
some of the cascades were overzealous and we revised to get tighter control
over cascading.

With an aim to being conservative and reproducing old behavior, I previously
patched `5.4.alpha` to add several extra flushes and simulate the old cascades.
However, it wasn't really as conservative as hoped -- because the "old
behavior" depended on the environment.  This patch brings us closer the "old
behavior".

See also: https://lab.civicrm.org/dev/core/issues/284

Before (Behavior in version <=`5.3`)
----------------------------------------

On systems with memory-backed caches, `flushCache()` had an aggressive
cascading side-effect where several named caches (`settings`, etc) were also
flushed.

On systems with a default configuration (SQL+ArrayCache), `flushCache()` had a
very limited cascading effect -- it *only cleared the in-process ArrayCache*.
The bulk of the cache content was preserved in SQL.

Before (Behavior in version ~= `5.4.alpha`)
----------------------------------------

To simulate the cascading effect, `flushCache()` explicitly flushes a
half-dozen individual caches.  (These half-dozen are chosen to match the old
cascade list and exclude some new things which would problematic.)

On systems with memory-backed caches, this reproduces the aggressive cascading
effect.

On systems with a default configuration (SQL+ArrayCache), this amplifies the
flushing -- because it also destroys the underlying SQL caches.

This has the side-effect of significantly degrading performance of the test
suite.

After (Behavior with patch)
----------------------------------------

`CRM_Utils_System::flushCache` calls `CRM_Utils_Cache::singleton()->flush()`.

To simulate the cascading effect, `flushCache()` explicitly flushes a
half-dozen individual caches...  *but only on memory-backed* systems.

On systems with memory-backed caches, this reproduces the aggressive cascading
effect.

On systems with a default configuration (SQL+ArrayCache), this is closer to the
old behavior.  The bulk of the cache remains available in SQL.

Based on local spot-checking, this restores performance of the test suite.

Comments
----------------------------------------

Deep down, I don't really believe the cascading effect is a good thing.  At
some point, I'd rather just remove these bits.  But in absence of a crystal
ball to predict the side-effects of that, I think it's good to find a better
approximation of the old behavior.

Merge pull request #12588 from mattwire/5.4_backportcasefixes

Backport "Fix regression on case export" to 5.4

dev/core#291 Allow for field size to be set for password fields

Fix regression on case export from recent export fix

https://github.com/civicrm/civicrm-core/commit/3b4adc92793dccfa446cf66f0740edb543f110d7 changed the way componentmode is defined

It now seems inconsistent

Non functional changes towards shared functions in Core_Form_Task

Merge pull request #12578 from JKingsnorth/patch-10

(NFC) Update readme to link to GitLab instead of JIRA

Merge pull request #12577 from eileenmcnaughton/export_sql_columns

Export clean up sql columns

Merge pull request #12530 from colemanw/plainObject

crmRouteBinder - Don't convert arrays to objects

Merge pull request #12573 from pradpnayak/ThrowExceptionOnGetValue

Added code to throw exception on getvalue api call

Extract getMungedFieldName

Extract getSqlColumnDefinition off to processor class.

Note that I wrote test coverage that was pretty extensive on the output of this function earlier

 Update readme to link to GitLab instead of JIRA

crmRouteBinder - Don't convert arrays to objects

Merge pull request #12388 from pradpnayak/optionValuePaymentMethod-b

dev/financial/issues/24, Moved code from form layer to BAO and used api instead of BAO function

Merge pull request #12416 from pradpnayak/232

dev/core/issues/232, Some smart groups and some searches not returning any contacts

Added code to throw exception on getvalue api call

Moved code from form layer to BAO and used api instead of BAO function

updated explode function in custom search

dev/core/issues/232, fixed how contact sub type is using separator

Merge pull request #12556 from totten/master-prevnext-selection

(dev/core#217) PrevNext - Migrate selection methods

added unit test to search contact based on contact sub type

Merge pull request #12571 from civicrm/5.4

Add 5.3.2 release notes (#12570)

Add 5.3.2 release notes (#12570)

[reviewed, pending rebase] CRM-20703 - Event Contribution Created When No Payment Option Provided (#12367)

* CRM-20703 - Event Contribution Created When No Payment Option Provided

* throw form rule when amount block is active

Merge pull request #12569 from civicrm/5.4

5.4

Merge pull request #12568 from kcristiano/5.4

dev/279 - When Merging two contacts flip, prev, next not working

Merge pull request #12563 from eileenmcnaughton/enotice54

dev/core#276 enotice fix

dev/279 - When Merging two contacts flip, prev, next not working

Affects Joomla and WordPress

Signed-off-by: Kevin Cristiano <kcristiano@tadpole.cc>

dev/core#276 enotice fix

Merge pull request #12185 from eileenmcnaughton/entity_form_url_defaults

Entity form : Establish methodology to allow default values to be passed in on the url

Merge pull request #12561 from eileenmcnaughton/mailing

CRM-21768_NOFOLLOW_links_in_public_online_view_of_mailings

Merge pull request #12560 from scardinius/core-278

dev/core#278 Fix DB syntax error when try to search deleted cases

CRM-21768_NOFOLLOW_links_in_public_online_view_of_mailings

dev/core#278 Fix DB syntax error when try to search deleted cases

(dev/core#217) PrevNext - Allow swapping `getCount()` for purposes of contact-search

The `getCount()` function is used by both contact-search and dedupe-merge use-cases.

* Contact-search
    * `CRM/Contact/Selector.php:            $countRow = CRM_Core_BAO_PrevNextCache::getCount($cacheKey, NULL, "entity_table = 'civicrm_contact'");`
* Dedupe-merge
    * `CRM/Contact/Page/AJAX.php:           $iTotal   = CRM_Core_BAO_PrevNextCache::getCount($cacheKeyString, $join, $whereClause, '=', $queryParams);`
    * `CRM/Contact/Page/DedupeMerge.php:    $total    = CRM_Core_BAO_PrevNextCache::getCount($cacheKeyString, NULL, ($onlyProcessSelected ? "pn.is_selected = 1" : NULL));`

Our aim in developing `CRM_Core_PrevNextCache_Interface` is to allow contact-search to swap a MySQL
backend with a Redis backend -- and dedupe-merge should continue as-is (whether or not Redis is
available).  This basically means:

* Contact-search switches to using `Civi::service('prevnext')->getCount()`
* Dedupe-merge continues using `CRM_Core_BAO_PrevNextCache::getCount()`

Note that the `Interface::getCount()` is simpler than the BAO's variant. This is good because:

* Contact-search doesn't need as many parameters.
* Dedupe-merge still needs all the parameters.
* Adding all parameters would make it hard to implement on other backends. (This is esp true of SQL-style options `$join` and `$where`.)

(dev/core#217) PrevNext - Allow swapping `deleteItem()` for purposes of contact-search

The `deleteItem()` function is used by both contact-search and dedupe-merge use-cases. We can classify
several of these just based on the files:

* Contact-search use-cases. (These should be updated to use the interface.)
    * `CRM/Campaign/Selector/Search.php:     CRM_Core_BAO_PrevNextCache::deleteItem(NULL, $cacheKey, 'civicrm_contact');`
    * `CRM/Contact/Form/Search.php:          CRM_Core_BAO_PrevNextCache::deleteItem(NULL, $cacheKey);`
    * `CRM/Contact/Selector.php:             CRM_Core_BAO_PrevNextCache::deleteItem(NULL, $cacheKey, 'civicrm_contact');`
* Dedupe-merge use-cases. (These should contiue using the BAO.)
    * `CRM/Contact/Form/DedupeRules.php:     CRM_Core_BAO_PrevNextCache::deleteItem(NULL, $cacheKey);`
    * `CRM/Contact/Page/DedupeFind.php:      CRM_Core_BAO_PrevNextCache::deleteItem(NULL, CRM_Dedupe_Merger::getMergeCacheKeyString($rgid, $gid, $criteria))`
    * `CRM/Dedupe/Merger.php:                CRM_Core_BAO_PrevNextCache::deleteItem(NULL, "{$cacheKeyString}_stats");`

Additionally, there are two oddballs which are harder to categorize.

* `CRM_Contact_BAO_Contact_Utils::clearContactCaches($isEmptyPrevNextTable = FALSE)` deletes *all*
  prev-next cache-records (`CRM_Core_BAO_PrevNextCache::deleteItem();`).  It only does so in one
  scenario (as part of `CRM/Contact/Import/Form/Preview.php`), which has this explanatory comment:
  "Clear all caches, forcing any searches to recheck the ACLs or group membership as the import may
  have changed it."
* `CRM_Contact_BAO_Contact::deleteContact(...)` deletes any prev-next cache-records which
  reference a specific contact (`CRM_Core_BAO_PrevNextCache::deleteItem($id)`).
  I suppose this provides a low-grade form of referential integrity.

Part of me thinks those should be re-considered (e.g.  to use a hook/event -- and reduce the
coupling between `Contact` and `PrevNext` subsystems).  However, for purposes of dev/core#217, it
seems OK to send `deleteItem(...)` to both BAO (SQL-only) and service (SQL-or-memory) variants.

(dev/core#217) PrevNext - Allow swapping `getPositions()` for purposes of contact-search

The `getPositions()` function is used by both contact-search and dedupe-merge use-cases.

```
CRM/Contact/Form/Merge.php:      $pos = CRM_Core_BAO_PrevNextCache::getPositions($cacheKey, $this->_cid, $this->_oid, $this->_mergeId, $join, $where, $flip);
CRM/Contact/Form/Merge.php:      $pos = CRM_Core_BAO_PrevNextCache::getPositions($cacheKey, NULL, NULL, $this->_mergeId, $join, $where);
CRM/Contact/Page/View.php:       $pos = CRM_Core_BAO_PrevNextCache::getPositions("civicrm search $qfKey", $this->_contactId, $this->_contactId);
```

Our aim in developing `CRM_Core_PrevNextCache_Interface` is to allow contact-search to swap a MySQL
backend with a Redis backend -- and dedupe-merge should continue as-is (whether or not Redis is
available).  This basically means:

* Contact-search switches to using `Civi::service('prevnext')->getPositions()`
* Dedupe-merge continues using `CRM_Core_BAO_PrevNextCache::getPositions()`

Note that the `Interface::getPositions()` is simpler than the BAO's variant. This is good because:

* Contact-search doesn't need as many parameters.
* Dedupe-merge still needs all the parameters.
* Adding all parameters would make it hard to implement on other backends. (This is esp true of SQL-style options `$join` and `$where`.)

(dev/core#217) PrevNext - Make getSelectedContacts() more portable

This function is used one time -- when you run a search, select some
contacts, and perform a task (like "Delete contacts"), the
`CRM/Contact/Form/Task.php` displays a table with the names of the selected
contacts.

This patch makes the logic portable -- so that it can work regardless of
whether selections are stored in MySQL or Redis.

Before
------

* The contacts are selected `FROM civicrm_prevnext_cache WHERE cacheKey LIKE {$key}% AND cacheKey NOT LIKE {$key}_alphabet%`.
* The contact names come from `civicrm_prevnext_cache.data`, which has been
  pre-filled with either `civicrm_contact.sort_name` (for most contact
  searches) or `civicrm_contact.display_name` (for campaign respondent
  searches).

After
-----

* The selections are chosen with `FROM civicrm_prevnext_cache WHERE cacheKey LIKE {$key}%`.
* The contact names are loaded directly from `civicrm_contact.sort_name`.

Comments
--------

* The use of wildcards with `cacheKey` seems like a code-smell suggest a
  somewhat deeper problem in how `cacheKey` is understood.  However, for our
  purposes, it shouldn't matter.
* The before and after queries are very similar in how they use
  `cacheKey`...  and slightly different.  (Ugh.) Is the new one better or
  worse?  Well, look at how `CRM_Contact_Form_Task` uses `getSelection()`
  (for finding contact IDs, which feed into the task logic) and
  `getSelectedContacts()` (for finding contact names, which are displayed to
  user).  If the subtle difference in `cacheKey` filtering matters, then our
  UX is buggy because we're showing the user one contact-list (based on old
  `getSelectedContacts()`) and we're executing on a different contact-list
  (based on the old `getSelection()`).
* Is the old technique for getting names (querying
  `civicrm_prevnext_cache.data`) better than the new technique (querying
  civicrm_contact.sort_name)?  I haven't benchmarked, but I'm skepitcal.
  Both techniques transfer the full `O(n)` list from mysql to php.
  In typical usage, the size of `n` is limited by what an admin is
  willing to click through in the UI (which is probably a few hundred
  IDs). The contact tables is indexed by ID. Maybe... if you manually
  check several thousand records, it might make a small difference. But
  if you're clicking that many, then other things are also getting more
  expensive (like the actual task). In this case, it feels like an
  unnecessary optimization.

(dev/core#217) PrevNext - Sanitize the `getSelection()` contract

1. Improve docblock formatting
2. The `$entity_table` is never passed in. You can see this by grepping universe for `getSelection`.

(dev/core#217) PrevNext - Sanitize the `markSelection()` contract

The contract feels quirky -- e.g.

* Who would guess that `markSelection()` defaults to `$action == 'unselect'`?
* What's the point of accepting `$entity_table` if it's never used?

Fortunately, this function is only called from `CRM_Contact_Page_AJAX::selectUnselectContacts`,
so it's fairly easy to audit and see that:

* The `$action` is always passed in -- it never relies on the default value.
* The `$entity_table` is never specified explicitly -- it always relies on the default value.

(dev/core#217) PrevNext - Migrate `getSelection()` from BAO to service interface

(dev/core#217) PrevNext - Migrate `markSelection()` from BAO to service interface

Include inactive count and sort using is_test

Merge pull request #12364 from JMAConsulting/dev-core-210

dev/core#210: Regex filter broken in Search Builder

Merge pull request #12543 from totten/master-prevnext-probe

(dev/core#217) PrevNext - Probe for best available implementation (memory-backed or SQL-backed)

Merge pull request #12555 from civicrm/5.4

5.4 to master

Merge pull request #12552 from colemanw/dedupe54

Handle 'Check for Matching Contact(s)' button with ajax

Merge pull request #11949 from magnolia61/Hide_waitinglist_for_past_and_registration_closed_events

Event Info: show waitinglist statusline only when registration is open

Merge pull request #12440 from mattwire/customfield_selectnooptiongroup

dev/core#244 Allow use of custom fields of type select without specifying an optiongroup