4.x: Adjusts CDI OciExtension to use runtime OciExtension for certain authentication tasks

[ljnelson]

Per request, this PR adjusts the CDI OciExtension to use the runtime OciExtension for authentication tasks.

(One thing I'd like feedback on is the change in behavior that will result in the absence of any configuration. In the existing CDI OciExtension, in the absence of configuration, a simple AbstractAuthenticationDetailsProvider (ADP) implementation will be tried first, followed by a configuration file-based ADP attempt, followed by an "instance principals"-based ADP attempt, followed, finally, by a "resource principal"-based ADP attempt. (This is governed by the enum order and is currently documented).

The runtime OciExtension changes the ordering.

I'm happy to make any changes that need to be made, or to allow this (maybe?) backwards-incompatible change to occur. Just let me know. (If the new ordering is fine, then I'll need to change a lot of Javadoc documentation.)

The PR is simple. The bulk of it simply checks (as before) to see if the user has registered any custom CDI beans for certain pieces (very unlikely, but if she has, we must respect them). (In the "sunny day" case this will of course not happen.) Then, in this case, which will be the ordinary case, as requested I've changed things so that the runtime OciExtension's ociAuthenticationProvider method will be called and its return value will be used.

[barchetta]

The change in ordering looks like a gratuitous incompatibility. Is there a justification for changing the ordering? I think our principle should be to stay compatible unless we have a justification to break compatibility.

[ljnelson]

I see two broad approaches:

1. Change the in-the-absence-of-configuration ordering in the runtime OCI extension to match the existing CDI extension's behavior
2. Somewhat laboriously interrogate the runtime extension's notion of what is available and effectively re-implement its default ordering in the CDI extension to preserve backwards compatibility (so bypass the in-the-absence-of-configuration ociAuthenticationProvider() logic (but that may be very method that drove the requesting of this change in the first place?))

I'm happy to make any changes that the community wants.

[ljnelson]

@tomas-langer Thanks for the approval. Do you have any feedback on the behavior change? Or is your feedback: "the behavior change is fine"?

[ljnelson]

Pausing this PR per request until changes are made to the "runtime" OciExtension.

[ljnelson]

Unpausing/undrafting now that, per consensus, I've amended this PR to make requested calls to newly available methods in the runtime OCI extension.

[trentjeff]

Can we add a test to ensure we are falling back to microprofile config?

[ljnelson]

Like:

// in a unit test somewhere
io.helidon.config.Config c = toHelidonConfig(ConfigProvider.getConfig());
OciExtension.fallbackConfigSupplier(() -> c);
assertThat(OciExtension.configSupplier().get(), is(c));

…? Or did you have something else in mind?

[trentjeff]

Yes, put something into the microprofile-config.properties file, and ensure that it got picked up by your code (which will internally use OciExtension, etc.). This will ensure that the fallback config is working to MP/CDI, and your code does not regress (i.e., confirms it is wired into the right OciExtension etc for auth)

[ljnelson]

OK…I can do this, but isn't this testing the io.helidon.integrations.oci.sdk.runtime.OciExtension class? Are you sure you want the test of how that class should behave in this Java module? There's no place in my code that could regress in this area (I just hand you a converted MicroProfile Config Config object and you go from there).

[ljnelson]

I added a test that hopefully gets at what you're looking for; not sure.

[tomas-langer]

LGTM

[tomas-langer]

LGTM