FEATURE: Speedup content cache flush by using cte in findAncestorNodeAggregateIds

[mhsdesign]

Followup to #5221

ContentGraph::findParentNodeAggregates becomes slower on bigger datasets. Due to the mass on executions on a cr:replay, this sums up very quickly. Via #5268 the query will be improved but this pr introduces ContentGraph::findAncestorNodeAggregateIds to make this operation as performant as possible.

• Adds comment for CacheFlushingStrategy strategies

• Introduces ContentGraphInterface::findAncestorNodeAggregateIds using native sql cte to speedup cache flushing. (see comment)

• Move test which creates illegal state to content graph package and use native sql to create the state to not run any catchup hooks. Previously we needed to handle the case of infinite loops to not crash:

  Prevent infinite loops
  NOTE: Normally, the content graph cannot contain cycles. However, during the
  testcase "Features/ProjectionIntegrityViolationDetection/AllNodesAreConnectedToARootNodePerSubgraph.feature"
  and in case of bugs, it could have actually cycles.
  The content cache catchup hook leverage this method and would otherwise be hanging up in an endless loop.
  That's why we track the seen NodeAggregateIds to be sure we don't travers them multiple times.

• fixes a bug where you cannot replay because the workspace is "missing" and no content graph exists

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

[dlubitz]

As far a I understood, this function needs to be more complex and return a set of pathways with ancestor nodes.
https://neos-project.slack.com/archives/C04PYL8H3/p1725605274115779?thread_ts=1725460465.658809&cid=C04PYL8H3

[mhsdesign]

Hmm but to get that right, does that mean that if implemented more complex also other node ids will be returned or just that all the node ids will be nicely ordered by dimension in a special value object. The latter i consider just an improvement and not critical. The idea is to improve the performance of the method via native sql at first. Its marked as @internal so we can improve the structure later?

[dlubitz]

the node ids will be nicely ordered by dimension in a special value object

Yes this one

Hmm but to get that right, does that mean that if implemented more complex also other node ids will be returned or just that all the node ids will be nicely ordered by dimension in a special value object. The latter i consider just an improvement and not critical. The idea is to improve the performance of the method via native sql at first. Its marked as @internal so we can improve the structure later?

But you don't improve that with this PR.
And even if it is marked as internal, i think we shouldn't put that into an interface if we already know, that we will change that.

[mhsdesign]

But you don't improve that with this PR.

i could try to do that ... emphasis on try :D or ask bernhard. But i get your point. Lets see how we can continue.

cc @nezaniel @bwaidelich @kitsunet

edit: and we def need behat tests for the method i forgot :D

[mhsdesign]

added behat tests and introduced cte query to improve performance. Its now ordered desc by the parentnodeanchor