Support Supplier in Config Builders

[trentjeff]

Passwords in the Vault may change over time. And features that require lively updates for configuration-based artifacts (e.g., Tls w/ cert rotation in #7279), will need the ability to get the updated password value when the certificate is observed to have changed.

We therefore would like to support something like:

    Supplier<char[]> keyPassword();

[trentjeff]

This ideally should be made a priority, as it will be needed soon in both 3.x and 4.x.

[trentjeff]

Here is a little more info for what is available today.

Customer Facing API

1. Subscribe to changes (the caller needs visibility to the Config instance directly (and this will not be made available with config builders). Example:

Config config = Config.create(...).get("whatever");
// events go up to the root level of the config tree
config.onChange(new Consumer<Config> {
	void accept(Config newConfig) {
		// old config == config
		// new config == newConfig
	}
});

2. Declared as a Supplier<> on the blueprint (and this is being proposed for this jira issue to be enhanced to spport):

// note that the user here will not be made aware if/when the underlying value changes. In order to do that we would need to additionally support #1 above (nice-to-have).
Supplier<String> config.asString().supplier() // will always give the latest value

It would be declared, processed, and supported by our config builder APT as follows:

Supplier<String> whatever();

For completeness, will also mention the provider side of this equation too.

Provider Facing SPI
There are two ways to accomplish this today. Implementers should support either or both PollableSource and/or EventConfigSource on their ConfigSource implementation.

1. PollableSource should be implemented by the provider to implement a polling (perhaps also caching) strategy for accessing the backing config system/source. The Helidon Config system is designed to call boolean isModified(S stamp); periodically to check for changes, and when it notices change the Config system will use the API onChange to notify accordingly.
2. EventConfigSource should be implemented by the provider to handle an external event (e.g., a restful endpoint enables a "force reload" event for example). In this case the provider should call void onChange(BiConsumer<String, ConfigNode> changedNode); to reflect the new value and will trigger the Config system's onChange to notify accordingly.