[FEA] Expand/customize dependecy loading introduced in fat-jars to work with the slim-jar too

[ldematte]

#1296 introduced "fat-jars": jars with embedded native dependencies.
In order for them to work, a OptionalNativeDependencyLoader, which extracts the dependencies to a tmp folder and loads them in reverse order, is introduced.
OptionalNativeDependencyLoader is invoked inside JDKProvider, before any native cuvs functions is invoked from Java, to preemptively load the native libraries from the desired binaries.

In parallel, in #1316 we are trying to do something similar/related: we try to load in the "regular" way libcuvs, to see if the load fails; if it does, we switch to the UnsupportedProvider to give users a meaningful and precise error message. Very similarly, this is done inside JDKProvider, before any native cuvs functions is invoked in Java.

We should come up with a unified mechanism, where OptionalNativeDependencyLoader tries to load the native library (libraries) in different ways based on whether we are in a fat-jar or slim-jar, to give users precise error messages for the 2 different cases.

[ldematte]

Two additional considerations:

• the unified mechanism can be dynamic (OptionalNativeDependencyLoader perform some introspection, realizes if it's slim or fat jar, and perform checks accordingly) or static (we have 2 different implementations of OptionalNativeDependencyLoader, one for the slim and one for the fat jar)
• we should probably rename it to NativeDependencyLoader

Re: the last bit: I would propose to make it fail if the load fails; it's true that in the case of the fat-jar failing to load the embedded .so means that the JVM will try to load them "the regular way", but is this something we want? It can lead to confusion -- the jar ships with libraries, but it may end up using different libraries. Something very difficult to understand and debug.

@mythrocks wdyt?

[mythrocks]

in the case of the fat-jar failing to load the embedded .so means that the JVM will try to load them "the regular way", but is this something we want?

I would have thought that's what Elastic would have wanted. The fallback is to ensure that we can use the same dependency loader, irrespective of fat-jar vs slim-jar.

I am supportive of changing this to fail loading if the native-libs are not found. I would have thought that would be cumbersome in the slim-jar case: We would need a different dependency-loader.

I'm sure we can work that out, though. 👍

[ldematte]

I would have thought that's what Elastic would have wanted. The fallback is to ensure that we can use the same dependency loader, irrespective of fat-jar vs slim-jar.

If we have to have one loader, yes. But I'm proposing to use a different dependency-loader.
If we can have a different dependency loader for the slim case, it seems you are supportive of changing this to fail loading, right?

I'm sure we can work that out, though. 👍

Yep, I combined it with #1316 and it's pretty nice actually. I'm just waiting for #1296 and #1314 to get merged so I don't run into a mess of conflicts

[ldematte]

The simplest implementation just does

public static void loadLibraries() {
    if (!loaded) {
      if (jarHasNativeDependencies()) {
        loadLibrariesFromResources();  // Your current code
      } else {
        loadLibrariesFromSystem();     // Code form #1316
      }
    }
  }

And I think it's clear and simple enough.

I can try to make this static instead of dynamic (which means: have different implementations of the dependency-loader class, compile both but insert each one in either the fat or the slim jar).
It can be done with profiles and/or build-helper-maven-plugin, but I feel like it would just increase complexity.

[mythrocks]

Yep, that's pretty clean. +1.