why: The Paypal followup donations

• are filling the DB unneccesarily
• are "weird" in the domain (scrubbing, duplicating, exporting, etc)
• fill up space in the FOC donation overview
• might also affect queries when the concept of "followup donations" is not taken into account (joining PPL payment table and querying for null parent payment IDs).

At the time of writing (April 2025) we have about 849131 recurring donations (of 4283735 Paypal donations overall, meaning ~19% of our donation data sets are redundant entries for recurring payments)
The more recurring donations we have, the more severe the problems will become.
SQL statement to check the payments:

SELECT 
  CASE WHEN payment_interval = 0 THEN 'one-time' ELSE 'recurring' END AS recurring_type,
  CASE WHEN parent_payment_id IS NULL THEN 'first-time' ELSE 'followup' END AS followup_type,
  count(*)
FROM payment 
JOIN payment_paypal USING (id) 
GROUP BY recurring_type, followup_type;

Implementation notes:
Donation bounded context:

• Change donation domain model to allow for multiple payments for a donation
• Make donation payments a many-to-many table (instead of having payment_id), tracking followup payments for a donations.
• Adapt BookDonationUseCase to behave differently when payment bounded context signals a "FollowupSuccessResponse": Don't create a new donation, instead add payment id to list of payment IDs.

Fundraising Operation Center:

• check queries of analytics and reports in FOC (if T320781: Use new payment tables in Fundraising Operation Center was not done, it should be done as a prerequisite for this ticket)
• rewrite donation export logic (take payments as source of truth, join donations as needed. Currently it's the other way around)