!!!TASK: Reduce complexity of ReflectionService

[kitsunet]

This change tackles some problems within the reflection service that stem from historically increasing complexity due to various caching mechanisms depending on application context and compile time status.

The aim was to cut down on this complexity, while ensuring that all existing use-cases continue working as intended.

This ultimately also fixes issue #3402 by providing the same reflection data across all possible contexts.

A few features and caches got deprecated with this change and could be breaking in the rare case you used the freeze package api in your code:

The entire concept of freezing a package is deprecated

What remains are the commands in the package controller, which are now all no-ops and deprecated to be removed with 9.0. This is to ensure deployment pipelines possibly calling freeze commands do not break with the 8.4 update.

Additionally the single method PackageManager::isPackageFrozen remains, while the rest was removed. None of the methods was ever api and it seems unlikely that someone used them in user-land code. isPackageFrozen however is at the very least used in Framework and Neos code and therefore remains until 9.0, but will now return false for every package.

Caches deprecated and unused

With the simplification two caches are no longer needed, both are still declared so that possibly existing cache configuration in user projects doesn't error, but both

Flow_Reflection_Status

and

Flow_Reflection_CompiletimeData

will no longer be used and any content can be removed.

The only reflection cache is now Flow_Reflection_RuntimeData, which makes the name somewhat deceptive as it is also used in compile time. To avoid backwards compatibility issues however it makes sense to keep the name for the foreseeable future.

Quick performance comparisons suggest that especially the initial compile from empty cache benefits from this change. Reflection updates in Development context afterwards seem to be on par with the existing code base.

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

[kitsunet]

Future steps here IMHO could/should be to transfer the huge array structure of reflection data into DTOs and possibly split code that creates the reflection into a Compiletime ReflectionService as we shouldn't need to reflect anything during runtime, therefore making the code easier to reason with. But I resisted from adding those changes here to avoid making it a needlessly large change for 8.4