!!! TASK: Interdimensional relatives for node move

[nezaniel]

Builds on: #4982

This replaces the cumbersome MoveNodeMappings DTO with the far more lightweight, but surprisingly even more capable InterdimensionalSiblings DTO.

Upgrade instructions

This is breaky for 3rd party packages since the event DTOs are part of the API

Review instructions

First: Don't be afraid of the number of LoC added. That's just proper test coverage for MoveNode, finally.

For the refactoring, further assumptions are made (and enforced via constraint checks and tests):

1) Pure edge operation MoveNode is considered an pure edge operation, meaning no node is actually touched. This was also implied before, since MoveNode explicitly never updated any timestamps. Thus, no OrginDimensionSpacePoints are communicated anymore, just siblings per affected DSP. Hint: Neos' ChangeProjection needs to decide how to deal with MoveNode. Its tests pass anyway.

2) Only one parent (at most) per move operation As the RelationDistributionStrategy already states: the variants will be gathered (more or less, depending on the strategy) at the new parent, if given. That also means: no implicit parent changes. If a given sibling belongs to a different parent, this will lead to

• a constraint check exception, if it's not really a sibling in the selected DSP
• the "sibling" being ignored in an affected DSP if it's not a sibling there

3) Succeeding sibling has priority over preceding sibling The given succeeding sibling (and its further succeeding siblings) will be checked for applicability. If none is found and a preceding sibling is given, it (and its further preceding siblings) will be checked instead.

4) Preceding siblings are evaluated if given and no succeeding sibling is given

5) Non-determinable siblings If no succeeding sibling can be determined for the move operation, there are three cases

• both siblings are explicitly given as null, which reflects the intention of "move to end"
• a parent id is given; We need to define a succeeding sibling (or null) here and chose null
• no parent is given: This is a no-op in the affected DSP; It will not even be part of the InterdimensionalSiblings because nothing happens in this DSP

Checklist

• [x] Code follows the PSR-12 coding style
• [x] Tests have been created, run and adjusted as needed
• [x] The PR is created against the 9.0 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

[nezaniel]

Also, what are those: [...] ?

It's untouched; I guess it fails on a newer / older PHPStan version

[nezaniel]

...and was fixed by just merging 9.0