TASK: Add onAfterHandle to CommandHookInterface

[mficzel]

This allows to return additional commands after the just executed one was handled. The onAfterHandle method gets the processed command plus all resulting events.

Example use cases: Add automatic translations to a freshly created node variant. Or create translations in a review workspace when changes are published to the live workspace.

Resolves: #5469

Upgrade instructions

Review instructions

Checklist

• Code follows the PSR-2 coding style
• Tests have been created, run and adjusted as needed
• The PR is created against the lowest maintained branch
• Reviewer - PR Title is brief but complete and starts with FEATURE|TASK|BUGFIX
• Reviewer - The first section explains the change briefly for change-logs
• Reviewer - Breaking Changes are marked with !!! and have upgrade-instructions

[mhsdesign]

this line must be executed after belows if ($fullCatchUpResult->hadErrors()) { as other-wise the cr is not up to date. Though im not sure if the hook should be run in the finally block if there was an exception like $concurrencyException ... probably not. So we need to change the finally block to be catch (\Throwable) and and run the onAfterHandle only if that was not the case.

[mficzel]

Moved the hook to the end of the finally block. In case the $fullCatchUpResult->hadErrors() this is never reached because an error is thrown before. That way the behavior is equal regardless wether Events or a Generator are beeing committed.

[mficzel]

Note: After this is merged the existing use cases should be updated as well and return empty commands onHandle.

1. https://github.com/neos/form-builder/blob/main/Classes%2FCommandHook%2FUniqueIdentifierCommandHook.php

[mhsdesign]

Events is not API! And contains the Decorated Event which is not api either and that makes sense as this is write only ... also the time stamps etc might be cool to have

The catchup hook or projections get:

onBeforeEvent(EventInterface $eventInstance, EventEnvelope $eventEnvelope)

But we dont have the EventEnvelope at hand at the moment as this is only a thing when fetching the events again...

as we also talked about performance maybe we dont want to have each hook load the events now ... but we could hand over them the event stream to look into it ... thought the stream is wayyy to low level and requires the internal EventNormaliser too ...

Renaming the internal Events to EventsToWrite and then introduce a Events thing with only EventInterface might be a way? For accessing its eventMetaData one would still have to use a catchup hook ...

Otherwise i really like the idea and added some cool tests 🧪 :D