Persistency and schema initialization handling

[ricardozanini]

Description

In a deployment with full persistency (di + job server + runtimes) there's a need to handle the schema and DDL operations in an eager way, before we have even a single sonata running.

1. Runtime:
   Currently a sonataflow service handles the migration, if set by the flyway configs

   This approach brings complexity because a sonata flow starting , with another version, can potentially change the DDL in a way which is unsupporeted/distructive. It makes sense even to block this and allow this only for a controller-originated action.

2. Data Index and Job service
   For those component, when using persistency, the schema initializtion is manually triggered.

There are various ways this can be addressed

• init containers
• sonataflowplatform controller, orchestrating a job and reporting the platform status accordingly

This means that the operator is responsible for the DDL of all components, and for the version that is used. Sonatas with custom image must use the base-image with the pinned version by the operator. otherwise no support.

Implementation ideas

No response

Related PRs:

• Add sonataflow postgres db migrator tool for data index and jobs service #517
• Add migrateDBOnStart property under persistence #507

[ricardozanini]

Incorporated by #522