dev/financial#6 Fix creating of template contribution when it has custom data

[mattwire]

Overview

https://lab.civicrm.org/dev/financial/-/issues/6

---

UPDATE: The original issue seems to be fixed between 5.44-5.45 - CiviCRM no longer crashes with a "data already exists" DB error. BUT it still doesn't do the right thing because any hook that tries to insert custom data on create gets ignored and the original values are used instead.
I've updated the test to demonstrate that a hook can insert custom data on a "Contribution.create" and the inserted data will end up in the database and not the copied custom data from the original.

It is good practise to insert entity+custom data in the same API call and this PR changes that to be the case, also uses API4 for a bit more modern-ness.

---

If there is an extension installed that automatically calculates custom data for a contribution on "create" this can cause CiviCRM to crash because:

Before

1. API3 Contribution.create runs and creates the new contribution (without custom data being copied) and triggers hooks.
2. Hooks fire (in this case ukgiftaid extension calculates and inserts it's custom data for new contribution).
3. $contribution->copyCustomFields() runs which then triggers a database exception because the data already exists.

After

1. API4 Contribution.create runs and creates the new contribution with copied custom data and triggers hooks.
2. Hooks fire (in this case ukgiftaid extension calculates and inserts it's custom data for new contribution).

Technical Details

Explained above.

Comments

@jaapjansma Are you able to review this one? It is a bug with the template contribution create.

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[jaapjansma]

test this please

[BettyDolfing]

test this please

[jaapjansma]

• General standards
  • Explain (r-explain)
    • PASS : The goal/problem/solution have been adequately explained in the PR.
  • User impact (r-user)
    • PASS: The change would be intuitive or unnoticeable for a majority of users who work with this feature.
  • Documentation (r-doc)
    • PASS: The changes do not require documentation.
  • Run it (r-run)
    • PASS: We tested this by installing Gift Aid extension, Form Processor in which we setup the repeating of a recurring contribution. We also created a manual payment processor type and we then created a contribution page with the gift aid profile and recurring contribution. We then created a new recurring contribution and repeated it through the form processor and checked for errors and whether the custom data has been repeated.
• Developer standards
  • Technical impact (r-tech)
    • PASS: The change preserves compatibility with existing callers/code/downstream.
  • Code quality (r-code)
    • PASS: The functionality, purpose, and style of the code seems clear+sensible.
  • Maintainability (r-maint)
    • PASS: The change does not sufficiently improve test coverage, but special circumstances make it important to accept the change anyway.
  • Test results (r-test)
    • PASS: The test results are all-clear.

@eileenmcnaughton or @colemanw can one of you merge this PR?