FEATURE: Introduce Workspace::hasPublishableChanges

[mhsdesign]

Introduces Workspace::hasPublishableChanges which will be used for following cases:

• to make Discard a noop (instead of looking into the event stream)
• to make ChangeBaseWorkspace fail if the workspace has changes (instead of looking into the event stream)
• to make DeleteWorkspace fail if the workspace has changes (future pr)
• for node migrations as it should be standalone package and NOT use the change finder (link)

Also its good to have some rudimentary changes concept already low level which will hopefully improved at somepoint in Neos X by diffing two content graphs or something.

Note also that the hasPublishableChanges will also return true for the case a NodeMigration was run on the workspace and created events like DimensionShineThroughWasAdded which are in fact publish able (which is NOT detected via the change projection !!!).

Implementation:

We decided for a simple hasChanges boolean flag on the content stream for now which will be set if there is at least one event that is considered a change: PublishableToWorkspaceInterface.
Technically an increment to count the events that are PublishableToWorkspaceInterface could also work but as there is no grouping of events per node aggregate id it would be hard to reason about the number and its meaning (it would be completely different to the change projections count)

We leverage the PublishableToWorkspaceInterface to ignore events like forking, closing and reopening, as they are not published to another stream.

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

[bwaidelich]

@mhsdesign wrote in slack
But instead of having a boolean flag i rather have already some simple incrementing count no? That would allow us to get rid of usages of the change projection like when deleting workspaces and saying how many nodes are in the workspace:
publishableEvents=publishableEvents+1
To be true a PublishableToWorkspaceInterface does NOT equal a change in the change projection as multiple set properties are deduplicated but i think it would still be a good think to have this low level count available.
The workspace would get a method hasPublishableChanges (wich never true for root workspaces) and maybe something countPublishableChanges though we should probably refrain from the whole changes term here as its already claimed by the change projection.
For example a DimensionShineThroughWasAdded event is also a change in terms for the workspace model but NOT respected by the change projection which only handles nodes.
Maybe we should use hasPublishableEvents and countPublishableEvents to be fully distinct?

One note regarding count vs flag:
A counter would only replace the change projection if we kept an individual count per type of edit (create, update, delete) per document node which would require a separate table.
For the time being I would go with the simple boolean flag and expose only hasPublishableChanges() on the workspace (since that can always be derived from the separated changes if we track them at some point).
Or do we need Workspace::countPublishableChanges() for anything else?

[bwaidelich]

This looks great, thanks!
Except for the implicit no-ops for invalid publish/discards, but you wanted to change that in a follow-up IIRC

[mhsdesign]

Removed the unrelated rabbit hole changes into a new pr: #5333

[mhsdesign]

we discussed in the weekly today that we want name the column hasChanges instead and merge it :)

[kitsunet]

interesting test failure because the test doesn#t say anytghing about no changes....

[kitsunet]

you know what, not following my own advice here. This has not too much to do with this change, I will revert my changes and merge this. WE can throw later... (as these changes are now gone here, I added throws for the no ops)

[mhsdesign]

jup thanks for attempting the change though... ill continue it in #5337 for beta16 :)