rethink configurations spec

[lburgazzoli]

As today providing configurations is done by a list of key/value pairs but that may not be very handing for tooling and in general for comprehension:

  configuration:
    - type: "property"
      value: "key=value"
    - type: "secret"
      value: "my-secret"

Wonder if we should provide a better organization, something like:

  configuration:
    - secret:
        name: twitter-directmessage
    - property:
        name: user
        value: my-user
    - property:
        name: password
        valueFrom:
          secretKeyRef:
            name: the-password
            key: password

which could give more freedom and would allow to use patterns commonly used in other kubernetes resources like referencing an entry in a secret or configmap

[lburgazzoli]

Relates to #1676

[github-actions]

This issue has been automatically marked as stale due to 90 days of inactivity.
It will be closed if no further activity occurs within 15 days.
If you think that’s incorrect or the issue should never stale, please simply write any comment.
Thanks for your contributions!

[squakez]

#2771 should be close this. With that work, the way to provide a configuration will be through container trait.

[squakez]

We manage them now via mount trait: https://camel.apache.org/camel-k/next/traits/mount.html