TASK: (Re-)introduce runtime cache on content repository

[mhsdesign]

i gave two promises :D for one we said we wont add the runtime caches for the release, but also i told christian ill do it :D so here it is, all to be discussed:

to cache all workspaces findWorkspaces() and getContentGraph(). Single calls to findWorkspaceByName() DONT build up a cache and if findWorkspaces() was not used before will not be cached. This is a little odd but simplifies the caching greatly.

History of runtime caches:

• building the content graph got more expensive with the need to fetch the workspaces current content stream id (last optimised via BUGFIX 4508 mark dependands of live outdated after direct change #5274)
• the default subgraph does not contain runtime caches anymore Extract Content Subgraph in-memory caching #5243
• the content graph runtime cache was removed via TASK: 5243 remove ContentGraphFinder runtime cache #5246
• the workspaces cache was removed when removing the old WorkspaceFinder !!! TASK: Add workspace content stream mapping to content graph projection #5096

Also in the history a LOT of rewiring was done over and over. So the final state of the ContentGraphReadModelInterface and the ContentRepository exposing these API's is relatively knew and allows us to implement caching AND invalidation at the same place.

The raw ContentGraphReadModelInterface still contains no caches and will be uncached inside a catchup hook.

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]

We could also introduce this cache in the adapters, thought the WithMarkStaleInterface is currently not working: #5506 - but as we are in sync mode we can invalidate the cache directly on handle.

And further we would be able to clear the cache on reset, which we CANT do at the moment as proposed.

[kitsunet]

I appreciate you doing this, but I would actually wait and plan this properly. I don't see obvious problems, BUT well long running process while something else changes workspaces... things could get awkward?

[mhsdesign]

jup my gut also says to wait rather than to go forward with this as there are still downsides:

• the cache is not flushed on reset
• the cache is disabled during publish instead of being flushed for each event (which would make catchup hooks using the cr more performant)
• the cr readmodel is actually uncached, which makes catchup using that not more performant
  • BUT having it not cached means constraint checks work always properly
• long running processes will get start to query and outdated workspace's content stream (if there was a publish etc) and thus return empty/null

in the end, we have lived some time without these caches, and it might be already good enough to ensure getContentGraph is NOT called in a tight loop (see bf6274b)

my reasoning to make this pr NOW is that we will NOT introduce runtime caches in a patch as "performance patch" as this could definitely hiccup some things. So if we decide we need them it will definitely be 9.x ;)

In that case we should definitely remove the WithMarkStaleInterface too: #5506