BUGFIX: Ensure users content stream is never left closed after publication

[mhsdesign]

Followup to publishing version 3: #5301

There are 3 cases currently that might lead to a closed content stream if $something went wrong during publication.

Case 1: Ensure all events are published BEFORE catchup

Otherwise, due to failures in projection or catchup-hooks the process would be immediately interrupted leaving a broken state.

For example a faulty redirect handler hook - that just listens to live events - would be called during publishing. That means the remaining part to publish is already commited and we know we still have work to do to fork the new user content stream and apply the remaining. But the catchup hook would interrupt immediately when the events were catchup'd live. We would be left with a CLOSED user content stream that contains the "same" events that went live during the rebase. Reopening would not help at that point. This is why we must ensure that all events are published BEFORE we do the first catchup.

Further implications:

• running catchup only once should be more performant
• we cannot refetch the current content stream version for what where previously "subcommans" (forkContentStream) but we must pass $expectedVersions around from the outside
• we should not run constraint checks after the first yield as that would still operate on the old state. Thus all checks are combined above
• closing the content stream will not be catch up'd directly meaning that another process will not get an error because the content stream is not writeable but because due to the version in the database being behind it will get a concurrency exception

Case 2: Reopen content stream if base workspace was written to during publication

... and a ConcurrencyException is thrown

Introduces a WorkspacePublicationDuringWritingTest parallel test (with own cr) to assert that behaviour.

Case 3: Close content stream a bit later instead of having to reopen in unexpected errors

Previously an error in extractFromEventStream because the payload was not correct and yet has to be migrated would lead to a closed content stream which is of course persisted even after fixing the events via migration.

This is still save to do, as the closeContentStream will commit the close on the FIRSTly fetched expected version.

Same guarantees, different error behaviour in rare cases.

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]

I think it's a great start and the LoC balance is negative even:

[bwaidelich]

Some, probably semi-helpful, comments. Looks great otherwise

[bwaidelich]

+1 by reading and running the tests

[dlubitz]

Look good by reading. But as a disclaimer ... I'm not that deep into this topic to fully understand. 🤷‍♂️