BUGFIX: Migration to correct order of removed node events

[mhsdesign]

Resolves partially: #5364 a replay from previous betas works again
Resolves: #5352 by fixing the replay allowing users to upgrade to beta 15

migrateevents:reorderNodeAggregateWasRemoved

Upgrade instructions

Review instructions

The idea to solve the replay for both cases (when structured nodes were repaired, and when a node was moved after deletion) we could just reorder all the NodeAggregateWasRemoved events to the end.

I tested that replaying works again for both bugs.

The only downside is that the removed nodes would temporarily reappear in every workspace as they are now outdated and have to be rebased. But that can be automated as well :)

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]

As discussed with Denny, Christian, Sebastian, Bastian and others this is wrong in the sense of event sourcing as the history is changed but the best solution we have. Lets merge it and have it for beta 16!

[nezaniel]

Aye, reordering is bad, then again the events never should have happened in the previous order in the first place. So this is actually correcting history.

[mhsdesign]

can these delete from and below the commit statements get tooo large? I tested it with 800 events to delete and publish at once and that worked.

[nezaniel]

Worked for my project, so +1

[nezaniel]

works for me

[mhsdesign]

We found out that there is a catch after all. Its is not correct for every case to move the removal to the end.
In the case

• create node abc
• remove node abc
• create node abc

the remove node MUST be in the middle position. Otherwise there will be a duplicate node entry in the content graph because we dont have constraints, and the document uri path constraint variant is violated.

This is not a problem with user generated content but for imports with deterministic node aggregate ids (which have been deleted and recreated) this will fail.
For now those projects must not apply this migration then. In case there is a project which still needs this migration but cannot use it we need to offer another way - which will be hard.