TASK: Introduce global getConfiguration() and cleanup configuration provider

[mhsdesign]

Depends on #4011 and introduces e2e tests for it.

1.) Move editPreviewModes to actual neos ui "configuration" instead of "frontendConfiguration"

Now that the "configuration" is cleaned up an only contains real configuration - no state, no endpoints - the question is how does it differ to the "frontendConfiguration" and shouldnt the one be part of the other?

From what git tells me it was like this:

The "configuration" in the bootstrap existed but specifically to pipe the "editPreviewModes" to javascript the "Neos.Neos.Ui.frontendConfiguration" settings was created. This was sorely home to the "editPreviewModes" key and its options which were made available from the original location in Neos.Neos.userInterface. To access these in javascript a new "editPreviewModes" registry was created which was filled by the items in frontendConfiguration.editPreviewModes. -> change 2016 #425

One year later it was discussed in slack how to make settings overall available from plugins to the ui (https://neos-project.slack.com/archives/C0U0KEGDQ/p1507709786000036)
The "frontendConfiguration" stuck out as option in the settings with the potential to easily do this. The change 15afda4 replaced the dedicated "editPreviewModes" registry with a "frontendConfiguration" where all settings from the "frontendConfiguration" were made available to.

Now today we end up with the configuration and frontendConfiguration where the former is not extensible. As we alias the editPreviewMode configuration in the "frontendConfiguration" and dont define it there and as this value is an integral part or neos it makes now more sense to put it into the "configuration" and thus get rid of the odd RenderingMode helper - in hindsight this is quiet ironic as the frontendConfiguration was initially made for the rendering modes and now we end up almost not using it anymore.

Future of the "frontendConfiguration"

The neos ui only uses this setting for the "hotkeys" but they are odd and broken so actually we dont rely on that much.

For plugins the frontendConfiguration is still the (only) place to add custom values.

Now an alternate future of the "frontendConfiguration" would be to host everything including the editPreviewModes and the nodeTree loading depth but these values are configured in "Neos.Neos.userInterface" and will probably stay there and should not be replaced by an alternative like "Neos.Neos.Ui.frontendConfiguration" (especially as the "editPreviewModes" are so deep integrated in Neos.Neos that they will need to stay configured there)

2.) Separate state from configuration -> move the allowedTargetWorkspaces into the redux store

previously these options where fully static and part of the "configuration".
But this is misleading, the information depends on other workspaces and thus the database. It is not configuration.

Now they will also be updated when const {getWorkspaceInfo} = backend.get().endpoints; is invoked.

During changes only the totalNumberOfChanges are recalculated but not all the allowedTargetWorkspaces

3.) Remove endpoints from initialData configuration by using <link tag and prefetch for node type schema endpoint

this approach was already started for translations via #3804 and now the second endpoint is gone as well.

4.) E2E tests for extensibility API

Introduces automatic e2e test to ensure the newest adjustments to our extensibility api are tested before we even publish those to npm.

For that the e2e test distribution now ships a plugin which is build using the extensibility api from the project via yarn workspace.

To build them use

yarn workspace @neos-project/neos-ui-extensibility run build
yarn workspace @neos-project/neos-ui-test-plugin run build

Which builds the extensibility api and then for Neos.TestNodeTypes compiles an example dummy plugin.

Testcafe then boots the real Neos Ui with plugin and uses an exposed global variable neosUiTestPlugin to interact with the plugin. In a later step the plugin could also be used to test that certain container extension points work or that a custom ck plugin can be written.

 - Manifest boot
 - Create and access custom registry
 - Neos Ui Configuration Access
 - Frontend Configuration Access
 √ Extensibility Plugin Api - Check plugin status via developer api (console)

What I did

How I did it

How to verify it

[mhsdesign]

@Sebobo following (internal) changes have been made

As we do not have a strict guideline as to how a plugin should behave to be supported across patch,minor or major versions its never easy to judge an internal change like this. Many parts of the Neos Ui carry a warning in code with them if someone extends those but thats just warnings. As most packages are exposed via the extensibility api I with my knowledge could build a plugin which could observe every detail what changed here but that is only because of my deep knowledge of the ui. None of these changes should matter to a Neos Ui plugin as they are core details:

• the endpoints translations and nodeTypeSchema no longer reside under configuration.endpoints
• the frontendConfiguration no longer carries the editPreviewModes setting and does not use the internal (new) helper Neos.Ui.RenderingMode.findAllSorted()
• redux sagas no longer receive the {configuration} as parameter
• when using the @neos() decorator neos.configuration is no longer available
• the state information configuration.allowedTargetWorkspaces is no longer stored as configuration but in the redux store

[Sebobo]

Looks good, thx

[Sebobo]

Like this, it's breaking extensibility without supporting the previous ways of accessing the frontendConfiguration.

[Sebobo]

Looks good, just a variable name change would be nice.