[Feature] Support business configuration management at the application level

[ZhongsJie]

Is your feature request related to a problem? Please describe.

In the actual enterprise implementation process, in order to reduce application size and effectively improve maintainability, it is necessary to abstract business-level configuration, provide application-level configuration management capabilities, and complete configuration content sharing between applications.

The current problems are as follows:

1. The component type Ref-Object can support the delivery of the ConfigMap of the Hub-Cluster to the Managed-Cluster, but it requires the object to exist in the cluster and manually associates the objects in the storage trait for business configuration. I think business configuration is a trait that needs to be independent and have the ability to reference metadata to increase the readability of the application.
2. At the same time, for the shared-resource policy to be provided in pr (#4213) , it can complete resource sharing, but it still needs to clear the modifiable entry. At the same time, when there are too many applications managed by users, sharing ConfigMap to realize configuration reuse will bring about the unknownness of changes, forcing users to understand the scope of influence of business configuration. IMO, the complete sharing of underlying resources should be avoided as much as possible at the business configuration. Users only need to care about the configuration content.
3. The current configuration capability (storage trait) provided by the application will cause the expansion of the application specification. With the increase of configuration content, its readability and maintainability will be greatly reduced, and the number of applications that can be managed will be limited.

Therefore, it is hoped that KubeVela can have the unified management capability of configuration. It can use the Ref form to relieve the pressure of application expansion. At the same time, the configuration management can be completed independently of the application, so as to realize the reuse of configuration content. Describe the solution you'd like

We can try to introduce the trait of config to manage business configurations such as ConfigMap and Secret. The UX layer provides a configuration management interface that supports users to pre-fill the configuration. The generated configuration metadata can be carried by ConfigMap or DB but differentiated from ref-object capabilities, and a provider of DynamicLoadTraitResource is provided to complete configuration conversion and support configuration delivery.

- type: config
    properties:
        - name: zsj-cm-1
          mountPath: /mount/test
          dataRef: nginx-conf
          version: v1
          encrypt: true

Topics to be discussed

1. When the configuration is stored in an external data source, whether the distribution and conversion of the configuration need to be upgraded to an independent controller. In this scenario, the configuration needs to have the GC capability to support the effective recovery of the corresponding resources during the application life cycle. Can ResourceTracker monitor secondary resources?
2. Need to effectively control the order in which resources are delivered. #4143
3. When trait only uses a ref to describe the specific configuration, version management needs to be performed for the configuration to support operations such as rollback.
4. How components perceive configuration changes and thus have the ability to proactively update. #4161
5. How to support canary release scenarios at the configuration level.

Describe alternatives you've considered

Additional context

[Somefive]

What do you mean for "ResourceTracker monitor secondary resources"? Like patterns like ResourceTracker->Deployment->Pod?

[ZhongsJie]

Yes, if config works independently as a controller, it will need to monitor the resources generated by config and support effective recycling.