Fix for #1579.

Merge pull request #16457 from colemanw/api4doc

APIv4 documentation & code cleanup

Merge pull request #16472 from eileenmcnaughton/cn_for_now

Revert "Remove unreachable code lines."

Merge pull request #16466 from mattwire/recurringentity_copy

Call hook_civicrm_copy for RecurringEntity

Merge pull request #16471 from totten/master-psr-log

composer.json - Relax psr/log constraint. Improve D8 compatibility.

Revert "Remove unreachable code lines."

In the course of https://github.com/civicrm/civicrm-core/pull/16462
I concluded that there might be (untested scenarios) where this would still be hit.

In #16462 I adopted a cleaner (tested) approach. However, I think it's unlikely that
will be merged before 5.23 is cut so I propose reverting this change & re-reverting it
once the rc is cut as a more conservative approach. We can focus on getting #16462
wrapped up for 5.24

This reverts commit d7943ca7f7107c1466e687e876bddaf0f1998d99.

Merge pull request #16460 from colemanw/noInclude

APIv3 - Only scan files for deprecation checks in Entity.get

composer.json - Relax psr/log constraint. Improve D8 compatibility.

Overview
--------

This addresses a composer conflict that's reported when trying to install
on Drupal 8.7. For example, run these commands:

```
drush8 dl drupal-8.7.x
cd drupal-8*
composer require civicrm/civicrm-core:5.22.x-dev
```

This is a port of #16470 for `master`.

Before
------

The install fails because `civicrm-core` requires `psr/log:~1.1`, and something else
is prodding us to use `psr/log:1.0.2`.

```
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Installation request for civicrm/civicrm-core 5.22.x-dev -> satisfiable by civicrm/civicrm-core[5.22.x-dev].
    - Conclusion: remove psr/log 1.0.2
    - Conclusion: don't install psr/log 1.0.2
    - civicrm/civicrm-core 5.22.x-dev requires psr/log ~1.1 -> satisfiable by psr/log[1.1.0, 1.1.1, 1.1.2, 1.1.x-dev].
    - Can only install one of: psr/log[1.1.0, 1.0.2].
    - Can only install one of: psr/log[1.1.1, 1.0.2].
    - Can only install one of: psr/log[1.1.2, 1.0.2].
    - Can only install one of: psr/log[1.1.x-dev, 1.0.2].
    - Installation request for psr/log (locked at 1.0.2) -> satisfiable by psr/log[1.0.2].

Installation failed, reverting ./composer.json to its original content.
```

After
-----

It should work.  However, this is hard to demonstrate via `r-run` without merging.

Comments
--------

The substantive differences between `psr/log` in v1.0 and v1.1 relate to `LoggerInterfaceTest` and `TestLogger`:

https://github.com/php-fig/log/compare/1.0.2...1.1.2

However, `civicrm-core` does not use `LoggerInterfaceTest` or `TestLogger`, so it shouldn't matter.

For the standard tarballs which use `composer.lock`, this does have the side-effect of bumping up from 1.1.0 to 1.1.2.

Merge pull request #16458 from twomice/1573_extra_columns_contribution_detail_report

Fix for #1573: Extra columns for Contribution Detail report.

APIv4 Organize debug sql into a single array

Merge pull request #16469 from civicrm/5.22

5.22 to master

Merge pull request #16464 from WeMoveEU/core-1564-against-5.22

dev/core#1564 Fix category name for a/b test temporary table

Merge pull request #16463 from eileenmcnaughton/obscure

Fix obscure bug

Call hook_civicrm_copy when we copy entities using RecurringEntity

dev/core#1564 Fix category name for a/b test temporary table

Fix obscure bug

After upgrading to MacOS Catalina & MAMP 5.6 (latest) with php version 7.4.1 or 7.3.9
my site was unable to load CiviCRM with a segfault error. I traced it to this line & found that
phpstorm was highlighting the line it red as possibly subject to https://bugs.php.net/bug.php?id=62577

- taking phpstorm's recommendation allowed the site to load - the failure had been on parsing info.xml files

Merge pull request #16461 from eileenmcnaughton/api_test

Add require_once to api3TestTrait

Add require_once to api3TestTrait

I used this trait from an extension but it was used with apiv4 before apiv3 (it supports both).

I got an error because utils.php is not included by this file. It 'freeloads' off the fact apiv3 initialises
the file - but in fact the file that includes a function requiring a function
should have the require once - reduces risk & cognitive load

APIv3 - Only scan files for deprecation checks in Entiy.get

APIv4 - Pluralize entity name in docblocks

Fix for #1573: Extra columns for Contribution Detail report.

Merge pull request #16441 from eileenmcnaughton/event_pre

[REF] Interim code cleanup - make the usage of addPayments clearer

Api4 Replace - simplify by removing unnecessary fallback

Clearer docblock description of the defaults param

APIv4 Explorer - use OOP format for chained api calls

Passing an array into setChain works, but the more "pure" way is to pass an object into addChain.

Merge pull request #16446 from mattwire/wp_passlanguage

Pass language code to CiviCRM for Wordpress

Merge pull request #16397 from eileenmcnaughton/cont_setting3

dev/core#1558 retrieve setting credit_notes_prefix as  a 'real' setting.

Merge pull request #16449 from colemanw/docVars

APIv4 - Variable substution in docblocks

Merge pull request #16454 from colemanw/explorerDefaults

APIv4 Explorer - Better UI for defaults param

APIv4 Explorer - Better UI for defaults param

Merge pull request #16452 from mattwire/tokenrow_docblock

NFC Fix TokenRow docblock

Fix TokenRow docblock

APIv4 - Variable substution in docblocks

Replaces $ENTITY and $ACTION in docblocks to improve help text in the api explorer.

Merge pull request #16450 from eileenmcnaughton/ev_test

[NFC] Minor test cleanup.

Minor test cleanup.

Merge pull request #16438 from eileenmcnaughton/ev_clean

[REF] Pass params into function rather than this weird check for whether params exists.

Merge pull request #16447 from samuelsov/lab#1319

dev/core#1319 Fix regression with shared household address

dev/core#1319 UI - different label for household and employer

Pass language code to CiviCRM

Merge pull request #16267 from jitendrapurohit/dev-1471

dev/core#1471 - Add system status alert for deleted custom fields in …

[REF] Interim code cleanup - make the usage of addPayments clearer

This brings the condition back to the calling function which clarifies what is going on with it

Merge pull request #16437 from eileenmcnaughton/ev_back

Add unit test to back office form when a payment is made against a partially paid contribution

Merge pull request #16439 from eileenmcnaughton/part_odd

Respect form value for register_date on partipant form

dev/core#1558 retrieve credit_notes_prefix as a 'real' setting.

    This is part of work to convert the non-standard contribution_invoice_settings array of settings into settings in line
    with our standards

Extend checks in test

Merge pull request #16425 from colemanw/markdown

Use markdown in php docblocks & display in APIv4 Explorer

Merge pull request #16098 from MegaphoneJon/event-23-correct

event#23 - don't count non-counted participants on Confirm Registrati…

Respect form value for register_date on partipant form

The backoffice event registration form has a register_date field. In credit card mode it
does an awful lot of handling which is mostly for legacy code reasons but the net result is to ignore it
& set it to now. However, the field defaults to now & if someone actually changed it they would expect their change to
be respected. This removes that handling & just uses the field value entered. The field is always present from my
digging

Array formatting

[REF] Pass params into function rather than this weird check for whether params exists.

This function used to be shared with the online form & hence this form had to work to make itself 'look' like the other form.

It is now free to be it's own form

Merge pull request #16434 from eileenmcnaughton/cont_form_settings

[REF] Remove unused variable

Add unit test to back office form when a payment is made against a partially paid contribution

Merge pull request #16374 from colemanw/api4Delete

APIv4 - don't throw exception when updating/deleting 0 items

Merge pull request #16432 from colemanw/comments

Cleanup API_Exception usage

event#23 - don't count non-counted participants on Confirm Registration screen

Remove unused setting

Use markdown in php docblocks & display in APIv4 Explorer

Reformats some docblocks to use markdown, and uses the marked.js library
to display them in the APIv4 Explorer.

Merge pull request #16424 from eileenmcnaughton/cont_setting_handling

dev/core#1558 Data conversion for non-standard setting.

Merge pull request #16433 from eileenmcnaughton/fatal

dev/core#560 Replace fatal with exception

APIv4 - don't throw exception when updating 0 items

APIv4 - don't throw exception when deleting 0 items

Merge pull request #16431 from colemanw/explorerCss

APIv4 Explorer css tweaks

dev/core#1558 Data conversion for non-standard setting.

Per https://lab.civicrm.org/dev/core/issues/1558 the 'contribution_invoice_settings' 'setting'
does not follow our standard of one setting per key and this has led to all sorts of hacks in various places.

In trying to unravel this I eventually concluded we needed an interim step where the data would be
stored as the correct settings but set and get would still work on the deprecated settinng. The reason for
goinng this way is that I found more than one place where extension code is accessing these settings
and the amount of work to fix up all the places in core that access it and the settings form were too big
to deal with without a stepping stone.

With this merged the settinngs are correctly defined and a definition for the deprecated setting still exists.

Requesting the deprecated setting returns an array retrieved from the correct settings so is unchanged from calling
functions point of view. Saving the deprecated setting saves to the correct places. However, it's now also
possible to get & set the correct settings and once the core places are removed we will deprecate & remove the
deprecated setting.

Unit tests cover past & desired behaviour and the upgrade routine.

Replace fatal with exception

Merge pull request #16365 from mattwire/civicontribute_disabled_devcore547

dev/core#547 If CiviContribute is not enabled don't crash when calling ContributionPage.getoptions or Event.getoptions

Merge pull request #16392 from jaapjansma/dev_1522_tests

dev/core#1522 Handle space as thousand separator

If CiviContribute is not enabled don't crash when calling ContributionPage.getoptions or Event.getoptions

API Kernel - move params check to v3 where it's relevant

NFC - Comment & case cleanup

APIv4 Explorer css tweaks

Issue 1522: style formatting

Merge pull request #16398 from eileenmcnaughton/pref_form

dev/core#1558 [REF] Remove deprecated code from CRM_Admin_Form_Preferences

Merge pull request #15842 from totten/master-config-backend

dev/core#1387 Continue removal of "config_backend"

(dev/core#1387) ConfigSetting - Deprecation+guard for retrieve()/add()

These functions were traditionally used for accessing `config_backend`,
which was (mostly) dropped in v4.7 and became inert. However, the
functions are still referenced in a couple oddball cases.

Note that the references to `$domain->config_backend` are liable to raise
warnings if evaluated - since the field no longer exists on the DAO class.
Consequently, the extra `$hasBackend` guard should reduce warnings.

(dev/core#1387) Remove some lingering references to config_backend

(dev/core#1387) Remove config_backend from sample/dev setup

(dev/core#1387) FiveTwentyThree - Drop civicrm_domain.config_backend if it snuck in

This column was dropped in 4.7.alpha1, but it was still created on new installs, so

* Sites originating with 4.7 - 5.22 should have an empty copy of the column today
  (because it was defined in xml schema - but never used by live code).
* Sites originating with <4.7 (and subsequently upgraded) should not have the column today
  (because FourSeven.php previously dropped it).
* Sites originating with <4.7 (and not yet upgraded) should have the column with some data
  (because FourSeven.php hasn't run yet).
* It is unexpected that any site currently on 4.7-5.22 would have any data in that column.

Note: `dropColumn` has a built-in guard so it only drops the column if it
exists.

(dev/core#1387) Domain.xml - Drop config_backend

Merge pull request #15760 from colemanw/iconPicker

IconPicker widget improvements

Merge pull request #16405 from totten/master-test-codegen

Civi\Test - Allow `headless()->apply()` (etc) to execute without setup.sh

Merge pull request #16403 from totten/master-relurl

Allow most values of $civicrm_paths['XXX']['url'] to be relative

Merge pull request #16407 from totten/master-altpkgs-basic

Fix loading with alternate packages path (system-level)

Merge pull request #16406 from totten/master-menu-warn

CRM_Core_Menu - Fix warnings during local test run (dev/core#742)

Merge pull request #16409 from totten/master-altpkgs-ui

 Fix loading with alternate packages path (UI-level)

Merge pull request #16411 from colemanw/api4EntityDoc

Api4 docs improvements

Merge pull request #16423 from totten/master-setup04

composer.json - Update civicrm-setup

Merge pull request #16402 from eileenmcnaughton/part_test

[REF] Add test for line item, extract fn

Merge pull request #16422 from seamuslee001/contribute_summary_report_stats_hook

[REF] Ensure that the from is correctly modified in both the main que…

Add test for line item, extract fn

composer.json - Update civicrm-setup

Merge pull request #16421 from totten/master-config-php

composer.json - Explicitly set target PHP platform

Add in unit test of to verify the change

[REF] Ensure that the from is correctly modified in both the main query and in the statistics section of the Contribute Summary Report

composer.json - Explicitly set target PHP platform

Overview
--------

This refines the way in which `composer` resolves dependencies - so as to
prefer packages that are compatible with Civi's declared minimum requirement.

https://blog.martinhujer.cz/17-tips-for-using-composer-efficiently/#tip-%2315%3A-specify-the-production-php-version-in-%60composer.json%60

Before
------

Suppose that:

* The current minimum declared is PHP 7.0. (That happens to be the case at time of writing.)
* You locally use PHP 7.4.
* You wish to add or update a package.

`composer` may grab a version of a package that works on PHP 7.4 -- but is
not available/compatible with PHP 7.0. Then you start developing things under
the false expectation that the library will be usable -- and only discover the
problem later.

After
-----

`composer` should grab packages that are compatible with the declared PHP version,
regardless of the local PHP version.

Comment
-------

* This is orthogonal to the question of *which* PHP version should be the
  platform for CiviCRM -- whatever version that is, this dynamic can play out.
  The patch doesn't change that.
* The value will undoubtedly change over time, which has a small maintenance
  issue to keep the PHP constants in sync with the composer metadata.
  KISS solution: add a comment!

Merge pull request #16420 from civicrm/5.22

5.22 to master

Merge pull request #16417 from jmcclelland/1555b

avoid undefined offset and uninitialized key errors on upgrade - dev/core#1555

APIv4 - Add docblocks to base classes

Merge pull request #16419 from civicrm/5.22

5.22

Merge pull request #16418 from seamuslee001/5.22

Add release-notes/5.21.2.md

Add release-notes/5.21.2.md