!!!TASK: Remove support for Flow's custom class loader

[kdambekalns]

This drops support for the Flow ClassLoader – except for functional
testing. There it's still used to load test classes & fixtures.
If you still used the FLOW_ONLY_COMPOSER_LOADER environment variable to fallback to the old Flow autoloader, you need to update your package to use proper composer autoloading via autoload section.

[kdambekalns]

Getting the tests to run without the class loader would be awesome, too…

[albe]

See also #2771 - I think we can get rid of the testing case if we manage to add autoload-dev section to the root composer manifest in the dev-distribution

[mficzel]

@albe that is not so easy as this would be required in all projects that use our unit tests as base. The clean way would be to extract the testcase base classes into seperate package that is dev-dependency. That way the tests for each package could be executed without depending on other packages tests.

[mficzel]

This one causes an error in Neos that should be addressed. Do not get yet why that happens exactly.

Required class "Neos\CliSetup\Command\SetupCommandController" could not be loaded properly for reflection from "Neos\CliSetup\Command\SetupCommandController".

The error may be a good sign and even correct.

[albe]

The clean way would be to extract the testcase base classes into seperate package that is dev-dependency. That way the tests for each package could be executed without depending on other packages tests.

But how would that make autoloading for Neos\Foo\Tests\X classes work? Those namespaces then need to be listed in the autoload section of all packages that contain tests, no? Which means cluttering the production autoloader with testing namespaces?

[mficzel]

Maybe this will solve this problem neos/neos-development-collection#3680

[mficzel]

With this change things broke that should not have worked in the first place. Fine by testing but not fully understanding.

[albe]

Fine as is, let's tackle the bigger fish for next major