JEP: Support * expressions to expand multiple Environment properties to a token separated list.

[alcarraz]

Summary

Allow several properties that match a given pattern to be expanded as a token separator list.

Goals

• Allow components of a list to have a name in the environment properties file.
• Maybe: enable the gathering of shared subcomponent properties in a list, so if we need to reference all properties in the form xxx.*.yyy we do not need to define an extra property for that.
• Possible side effect: let different files inject additional values to a token separated list.

Description

Pasted from a Slack message so it doesn't get lost

We could discuss the semantics later, but for now, consider this use case, you have a SelectDestination participant, and there you have many bins for the same destination, let's say Visa o Mastercard networks.

You could, of course, have a line like this in your yaml:

visa.bins: "4444 5555"
mastercard.bins: "6666 7777" 

And in the routes:

<endpoint destination="visa">${visa.bins}</endpoint>
<endpoint destination="mastercard">${mastercard.bins}</endpoint>

If you want to have more descriptive names for your elements, you could even do this:

visa:
  debit.bin: 4444
  credit.bin: 5555
  bins: "${visa.debit.bin} ${visa.credit.bin}"

Or things like that.
But if you want to have "pluggable" elements, like adding an extra bin for dev testing in a separate env file, or simply having to type less, you could have:

visa:
  bin:
    credit: 4444
    debit: 5555
mastercard:
  bin:
    credit: 6666
    debit: 7777

And in the routes:

<endpoint destination="visa">${visa.bins.*}</endpoint>
<endpoint destination="mastercard">${mastercard.bins.*}</endpoint>

And you can add more bins in other files, not that I can think of a use case for bins, but maybe for other things.
The implementation would be pretty straight forward (but not performant unless we cache the expanded values), like just filter the property keys by prefix.

We can even have an optional extra character (or string) for the separator.

Alternatives

I can think of implementing this as a custom EnvironmentProvider that could be enabled if some system property is missing, maybe we could talk in another discussion about a standard way to define feature flags, or preview features.

There are also different ways to implement the semantic, there are at least three basic options for the * semantics, that could easily expand to more:

1. Just to define a prefix, and all include all the flattened properties that just start with what comes before the *. This would be the simplest to implement, and the most general, but probably the trickiest to use.
2. Only consider it if it is after a dot and then, again, as a simple prefix.
3. Same as 2, but only consider properties that have no dots after. This would be like the java wildcard imports.

There could be a variant of all of them where you could put as many * like in a glob pattern in a shell. This could be useful for things like referencing all the yyy properties. We could even implement modifiers to let the user state the meaning.

The implementation is quite simple, and the environment could just cache the property as a property that has the key xxx.yyy.*. If it is present that is used, if not, it is calculated and saved.

The useful thing about the variant, is that then you can have ${xxx.} in one place and ${.yyy} in another. Allowing you to not having to define new properties if in some place you need, for instance, all the bins, again a bad example since I don't know if there could be a legit use case for that.

Risks and assumptions

This can be tricky with circular dependencies, so we need to consider how to handle them, e.g.:

xxx.yyy: ${a}

a: ${xxx.*}