feat: support @runtime views

[BobdenOs]

Replace view references when they are annotated with @runtime.

This is an opt-in version of #141.

• Replace @runtime views with their definition query
• Turn on for the Bookshop services
• Support for localized views (localized columns are not represented in the query)
• Support for @fiori.draft.enabled entities
  • Support for CREATE
  • Support for SELECT
  • Support for SAVE (cqn4sql query conflicts with resolveView)
• Performance (details)
  • Support for reduced view columns
  • Support for view flattening
  • Support for join removal
• Support UNION views

Performance Improvements

The primary performance goal of allowing for runtime views is to reduce the number of views deployed into the database. This comes at the cost that the SQL statements send to the database are larger as they include the tree of runtime views inside the query.

View flattening

When walking over the view tree it is possible to flatten views into a smaller number of queries. If there are a number of projections which rename certain columns. This renaming can be done in a single shot which removes redundant information. The main goal of an optimization like this is to reduce the size of the generated SQL statement.

Reduced view Columns

As the query is known at the point the runtime view is addressed. It is possible to reduce the columns the view exposes to only the columns used inside the consuming query. When this is done for columns that include path expressions the correlating join will automatically disappear from the final query representing the runtime view. Which has been shown in earlier experiments to enable exponential performance improvements for all supported databases (#892).

Join removal

Very similar to the Reduced view Columns concept, but instead removing the path expression from the view definition it is possible to identify the columns that are being sourced from a join query in the view and remove the unused joins from the view definition. Which will prevent the database optimization logic from having to identify the cardinality of the join to determine whether it is required to execute the join. As the CSN model has more metadata information available to it then the databases have available to them it is more straight forward to identify the cardinality of the join allowing for quicker removal tactics.