Re-implement support for timed node visibility

[bwaidelich]

Prior to Neos 9 nodes had the internal properties _hiddenBeforeDateTime and _hiddenAfterDateTime that allowed editors to schedule content (de)publications ahead of time.

This approach has some severe caveats, especially in the more explicit event sourced world of Neos 9.0, mainly:

• Every cache layer has to take the timing properties into account and dynamically expire which adds a lot of complexity and fragility
• Since there is no explicit event for when the before/after timestamp is reached, it's not possible to react to that even though it is a very important thing to happen

There are some more issues, but the two above were the main reason why we decided to leave this feature out.

However, it seems that this is a common requirement for people so these are the ideas we had to re-implement this feature:

A backend module that allows editor to explicitly schedule commands (for now DisableNodeAggregate and EnableNodeAggregate) potentially with a custom view that allows to do that directly from the inspector.
A cronjob then picks up these scheduled commands and executes them in time (if it turns out to be a requirement to have this without an actual cronjob, we could add an option that triggers this via HTTP middleware or similar – looking up scheduled commands would be a matter of a very simple SQL query)

This approach has some advantages:

• It is more explicit, i.e. it is just the same whether a command was scheduled or executed by a user (it would still be possible to differentiate the two via the initiatingUserId metadata). Consequently all depending code (projections, catch up hooks, ...) don't have to deal with another concept and would "just work"
• We could allow scheduled commands only for the "live" workspace, reducing the risk of conflicts
• The concept could be extended to other commands (e.g. allow editors to schedule a change-set etc..)
• This feature could be implemented completely separated from the core (theoretically it could even be kickstarted as 3rd party package by some agency that needs it the most and later integrated to the core if it makes sense)

[kitsunet]

Thank you for being so diligent with the tickets and documentation, it helps soooo much <3

[dlubitz]

We discussed serveral different approches and concluded to start with a less inversive one.

• using node properties to store the hiddenBefore and hiddenAfter dates
• no extra read model
• we select nodes where the state has to be changed in a cli command (cron job) where the date has been exceeded and the visibility state is not as expected
• we dispatch a DisableNodeAggregate or EnableNodeAggregate command for selected nodes

Also we want to put the "Timable Node Visibility" feature in a dedicated package within the neos development collection.

Other open topics:

• migration of existing properties (Neos <9.0)
• UI changes to ensure, the proper initial visibility state

[dlubitz]

As we don't keep anyting hidden anymore, I would change the naming of "hiddenBefore" and "hiddenAfter" to the more precisly:

• enableAfter
• disableAfter

WDYT?

[lorenzulrich]

Good idea, a migration of existing Fusion code would be very helpful.

[dlubitz]

I created a ticket for this: neos/rector#41
And also for data migration: #4814