FEATURE: ContentGraphAdapter for write side access

[kitsunet]

The write side no longer uses any regular finders for checks but only accesses projection data via the new ContentGraphAdapterInterface.

Fixes: #4973

[kitsunet]

Few notes here for starters:

• I omitted visibility constraints everywhere as we can just assume "see everything" given that that was hardcoded before.
• I added csId + workspaceName to all the methods that need it, a tuple might really make this nicer to read, but it works
• I originally thought we expose the factory and not the implementation and you can grab an implementation bound to csId + workspace but there is a bunch of methods in there that do not rely on it and so it felt strange as you wouldn't have either information if you need methods that do not need it.
• it's huuuuuuge, I haven't gone over and tried to reduce it by merging similar functionality, but maybe that's an option.
• The interface and implementation should probably move to another place, I will snatch that from bastis PR.

[kitsunet]

Also I realized too late but why is e.g. the workspace projection in CR Core? it should be in the storage adapter implementations (so DBAL, postgres) etc. ? Same for the contentStreams...

[bwaidelich]

Also I realized too late but why is e.g. the workspace projection in CR Core? it should be in the storage adapter implementations

Is that related? But for the record: Those projections work with MySQL and PostgreSQL – If it was part of the storage adapter we would need to copy all of the implementations to both adapters. But I agree that it should be in separate packages

[kitsunet]

More note.... I guess the adapter needs a bunch more dependencies to actually be able to provide Node(s) results, we'll see how that works out, they are obviously all available when building it, but I would rather want to avoid adding them...

[kitsunet]

Also I realized too late but why is e.g. the workspace projection in CR Core? it should be in the storage adapter implementations

Is that related?

I tried to get rid of ALL access to finders within the handlers, so now I also took the worksapce and contentstream related methods into the adapter, which doesn't work because the DBAL adapter implementation then doesn't know about those :D

[kitsunet]

Now come the hard(er) parts in a way. The nitty gritty. Some of the missing methods (see linter errors) were removed by me because phpstorm didn't detect usage. The interesting question is which of those use cases do we consider valid "read" use cases that should use the content graph and which should use the new ContentGraphAdapter. I think the two controllers are probably real use cases and should be re-instated to work. the ContentCacheFlusher for example I would rather solve with the ContentGraphAdapter as well as the SiteServiceInternals...

All resolved for now, but I will probably poke a few other corners. Also now need to deduplicate the queries.

[kitsunet]

In our weekly 2024-04-19 we talked about how this adapter is maybe not worth the trouble and if we can solve the ugly contentStreamIdOverride differently without this. And it is indeed difficult to make assumptions for after introduction of node identity, but it is very clear to me that at a higher level commands and API will use workspaceName the queries (at least for the DBAL Adapter) will need a contentStreamId to work, therefore this translation will have to happen somewhere, IMHO the changes for NodeIdentity will just push this deeper into the read side making it even more annoying (e.g. due toContentSubgraphWithRuntimeCaches) to override for the few caess that we have. And those are valid cases as we apply commands with $some workspaceName to a contentStream that has (not yet got) this workspaceName.

This together with the (from the POV of the write side) convoluted API to read stuff lets me think that this change could have merit even IF we cannot at this point avoid using read models (IMHO this could be a later improvement though) and much easier to just change the write side interface for this.

Convoluted because we apply filters, visibility and a lot of other stuff.

I am still not in love with the triple factory thing, but the separation of APIs seems very sensible still.

[bwaidelich]

This is to be replaced by #5028 and I suggest to close the PR (we can still keep the branch for reference if needed)