FEATURE: Simplify publish workflow

[mhsdesign]

Based on #3910

The change #3759 introduced a new publishing confirmation modal that provides information and will run the publish or discard operation when continuing.
This guarantees that no publish is triggered accidentally and also that the Ui is locked during publishing so that its not possible to edit content which would raise a server error. The workflow looked like this:

We discussed a lot of pros and cons if the workflow should be simplified and to which extend mainly because the Neos 8.3 publish workflow was a simple one click operation with no further interaction.

TLTR: Minor publish operations - just publishing the document - should be simplified to be a simple one click operation like in Neos 8.3.

Reasons for simplifying the workflow of publishing the current document

• Initially the confirmation popup was also made to prevent mistakes when publishing
  • In the future we plan to insert additional information here in case a publish is different than normally, for example because changes in other dimensions are also published: PartialPublish / Discard vs Content Dimensions neos-development-collection#5387
  • -> but any possible warnings in here will probably be auto-confirmed because the editor is used to clicking "ok", and we loose capabilities to warn. Also publishing a single site is not considered dangerous and editors work well with that since ever.
• The modals second task was to block user input during the publish operation in the Neos Ui - at the time this was really important as changes during publishing could mess with the content repository in unexpected ways. Since the content repository is guarded against these race conditions preventing user input is just a matter of cosmetics as we dont want the user to run in any (planned) server exceptions. The solution is that the Ui will be blocked if the server is busy for longer time as during short publishings user interaction is humanly not possible that fast (see screencast below).
• The sophisticated workflow was also designed when publishing took severely longer also for simple changes. It was anticipated that editors might leave the Neos Ui window and come back when the publishing was finished. For that reason a result dialog was shown so the editor could know where work was left of. Now with the content repository behaving faster (via the synchronous mode) publishing with a few changes is not noticeable.
• Other operations like synchronisation, discard, discard all and publish all still require the initial confirmation dialog and will present also a result dialog. These workflows are less important and dont require a short path for now. Any optimisation here too will also require probably a bigger refactoring to avoid dead code paths for then unused confirmation steps. Further we found that the confirmation step for these actions makes sense and gives us more transparency to show what the effect is of this action - possibly allowing a small review diagram like in the review module. Also for destructive actions like discard a confirmation dialog is generally good practice.

Case 1.) For quick servers the publish is done in no time while the Ui indicates this with a spinner in the publish dropdown:

Bildschirmaufnahme.2025-01-23.um.10.45.19.mov

Case 2.) For slightly longer operations after a timeout a modal with animation is shown (like in the other workflows) so that its not possible to make changes via the Ui, which would cause an exception:

Bildschirmaufnahme.2025-01-23.um.10.46.21.mov

[pKallert]

I did some tests locally and ran into an interesting use case:
When I have a conflict on Page 1 and then use the "simple" publish on Page 2, the conflict resolution opens. This is a little bit strange from the user's point of view, could we allow publishing the page even if there is a conflict on a different page?

[mhsdesign]

This change was approved in the Neos 9 meeting on 24.01 by christian paula and denny.
Also markus, paula and me drew up this board https://excalidraw.com/#room=8296ae6b0810f548d8cc,Nmi4adDo483gqJcPUpijvg documenting the previous state and the here introduced solution.