Add new use cases to the donation bounded context that represent different state change actions:

• Mark a donation as moderated or unmoderated. Currently, the Fundraising Application automatically moderates donations text violations and comment violations, but in the new implementation, those actions should be separated.
• Soft-delete a donation or remove soft-delete status
• When a donation is approved, the approval use case should send the confirmation mail (but only the first time the donation is approved).

Implementation notes:

The current database implementation (mis)uses a single field for moderation and deletion - status. It stores the previous status as text messages in the log property in the data blob for cases where the deletion/moderation is reverted. The new implementation must provide a new, more high-level API that hides the storage details:

• The Donation domain class should get markAsDeleted, removeDeletionMarker, markAsModerationNeeded and markAsApproved methods (naming at your discretion). markAsApproved should indicate if the donation was approved before (moderators in the the Fundraising Operation center can approve and un-approve a donation multiple times).
• The DoctrineDonationRepository is responsible to look into the database entity before the update and
  • write the previous status into the log property in the data blob when donations get moderated or deleted
  • read the the previous status from the log property in the data blob when donations get moderated or deleted

This architecture will allow us to replace the database implementation without touching the domain model, use cases or controllers.

The logic for changing the status in the Fundraising Operation Center is in app/model/Donation.php and src/DonationStatusUpdateService.php. Have a look at the unit tests for src/DonationStatusUpdateService.php, they should outline most of the required functionality.

The controller of the Fundraising Operation Center does not send the confirmation mail via SMTP. Instead, it uses FundraisingFrontendService to send an HTTP request to a special route on the Fundraising App, which sends the email. Changing this behavior is not part of this ticket! Instead, we track that issue in T254028: Enable Mail-Templating and -Sending from Fundraising Operation Center.
Only move FundraisingFrontendService to the bounded context and introduce a DonationConfirmationNotificationInterface, making both FundraisingFrontendService and DonationConfirmationMailer implement that interface. When we have a better solution for the questions posed in T254028: Enable Mail-Templating and -Sending from Fundraising Operation Center, we can get rid of FundraisingFrontendService and use a different implementation.

The controller in the Fundraising Operation Center contains another action for modifying the expiry date of the update token, but that functionality will be removed, so no need to port it.