TASK: Remove obsolete findContentStream(s)

[mhsdesign]

see https://neos-project.slack.com/archives/C04PYL8H3/p1730469137241279

these methods were introduced in beta15 to replace the usages of the @internal content stream finder in the content stream pruner.
With the overhaul of the content stream pruner, we dont need to access all the projections content streams anymore, but it was forgotten to remove these helpers.

For testing we now utilise the same trick as for countNodes by acquiring the read model directly.
While this requires a work around, we discussed that we are fine with this method getContentRepositoryServiceFactoryDependencies():

https://neos-project.slack.com/archives/C04PYL8H3/p1729592139706169?thread_ts=1729581753.563249&cid=C04PYL8H3

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]

or maybe, if we like it or not, we should just expose the ContentGraphReadModel ON the content repository directly as @internal method with note to be careful. We cannot avoid people ditching security (see $context->withoutAuthorisationChecks) and as this ContentGraphReadModel will soon to be exposed for catchup hooks as api already ...

[bwaidelich]

IMO it's not about preventing folks to intentionally circumvent security – they always can, as you pointed out.
But the API should make that cumbersome or at least very very explicit. And exposing a internal concept in an api-object is a code smell IMO (even if it is marked with warnings)

I think, we should just have some custom "accessor factory" in our CRTestSuiteTrait that is instantiated once and provides read-access to all required dependencies.

[mhsdesign]

that is instantiated once

Okay agreed, but that escalated to a (possibly) bigger change: #5341 so lets have this optimisation separate for later.

[kitsunet]

I would rather merge many small changes than always having these huge refactor everyhting things...

[mhsdesign]

oke so are you fine with the code now? @kitsunet

[mhsdesign]

Actually with the discussion here https://neos-project.slack.com/archives/C04PYL8H3/p1731148458597629 we think that we need some Version available to the cr user after all:

Okay today we discussed if we should introduce some concept like idempotency key / rebase token to solve this (which would be either a hash of the base version or possibly a hash of all the events that failed last time)

but bastian pointed out that we have this kind of versioning already with the Version and introducing this to the Workspace read model would make sense for this case and allow it to be used here for the RebaseWorkspace command as argument.

Its only a little "shady" that the version of the workspace is actually the one of the content stream ... that would mean that all the node command handler fetch the version currently via the cs readmodel while i was just about to change the workspace command handling to use the same version then thats inside the Workspace for simplification.

But another gain would be that for the import we could relatively early assert that the workspace better be 0 and fail early.

So in case that we find out that its wrong if the Workspace has this version information, we probably should keep the findContentStream thingy api?

[mhsdesign]

As discussed with christian we are rather fine with adding the version on the workspace and push the whole content stream fetching back into the land of internals. There is no need for them to be public in any way.