4.x: Adds OciSecretsConfigSourceProvider.java

[ljnelson]

Addresses issue #4238.

Description: OciSecretsConfigSourceProvider is a Helidon SE ConfigSourceProvider that creates a ConfigSource that sources its information from an OCI Vault using the OCI Secrets Retrieval and Vaults APIs. The ConfigSource so created is, as I've been directed, a NodeConfigSource and a PollableSource. Its "have I been modified?" logic is based on metadata also sourced from the vault.

This PR supersedes other PRs that I've made in this general area as it now follows the most recent instructions and directions in this area that I've received. It should be easily back-portable to the helidon-3.x branch. If I understand properly, it should be usable as-is by Helidon's MicroProfile Config implementation via already-present Helidon mechanisms for including ConfigSourceProvider implementations, though I'm not personally familiar yet with how to do this.

I will be closing and re-pointing other PRs here.

Once this PR is approved (if), I will backport it to helidon-3.x.

Documentation impact: There will need to be a couple of examples showing how to configure this ConfigSourceProvider in a meta-config.yaml. (Examples already exist showing how to configure other ConfigSourceProviders; this one is not very different.) Javadoc already exists in this PR to show usage and a sample configuration.

[trentjeff]

i'm still not seeing the name change or other pure unit test coverage here.

[ljnelson]

Could you give me an idea of what you would like to see tested? The reason I ask is because everything else about this is part of Helidon Config, so all of those mechanisms are tested. NodeConfigSources return NodeContent and the Helidon Config framework takes it from there. Everything else in this class is related to connecting to OCI and actually getting a secret. So I'm genuinely not sure what to unit test.

If you have a suggestion for the name of whatever test you're thinking of I am happy to use it.

[trentjeff]

There is some 400+ lines in OciSecretsConfigSourceProvider that should be tested since as it is right now there is nothing currently test covered in the normal case where the pipeline or developer typically does not have an $HOME/.oci/config present in their environment. I am suggesting we have some unit-test coverage on this code for the typical case. Perhaps even consider making more methods package private to be able to test them in isolation, eg. static boolean isModified(Instant pollInstant, Instant closestSecretExpirationInstant), static void completeAllSecretsTasks(Collection<? extends Callable<Void>> tasks, AutoCloseable secrets), Optional<NodeContent> load(Supplier<? extends Vaults> vaultsSupplier, Supplier<? extends Secrets> secretsSupplier, ListSecretsRequest listSecretsRequest) with some fakes or mocks, etc.