EPIC - Add support to multiple workflow definitions in SonataFlow CR

[ricardozanini]

Description

Currently, the SonataFlow CR specification only allows one workflow definition in the .spec.flows attribute. For users to use subflows they would need to create a specialized ConfigMap in the .spec.resources attribute so then the operator can mount these workflows in the pod's volume. From there, users can call these subflows from the main definition in .spec.flow.

The current approach presents the following drawbacks:

• Subflows are not tracked by the operator, hence no Knative objects or service discovery bindings are processed. This limits what users can do with sub flows;
• Subflows can not be called externally via HTTP REST calls
• Users must create a separate object (ConfigMap) to have them in the context
• If a sub flow also acts as a normal flow, the user will have to deploy it twice in the cluster (one as a CM and a copy of it in the SonataFlow CR)

Implementation ideas

To overcome the outlined drawbacks, we will introduce the .spec.flows which will hold an array of workflow definitions deployed together in a single pod, enabling users to call them internally as sub-flows or externally as they were common flows deployed in the architecture.

.spec.flows and .spec.flow can be defined at the same time.

Impacts

@treblereel This will impact the kn-cli manifest generation since we will drop CM support for subflows. There won't be a concept of "main" flow anymore.
@fantonangeli this may impact the UI, can you do an assessment?
@handreyrc This will for sure impact the integration with the Orchestrator. I'm unsure if the plugin is considering one workflow per deployment unit. cc @masayag to assess and help evaluating on Backstage, this is a requirement for apache/incubator-kie-issues#1181. @fjtirado fyi