Should we refactor jni layer to separate jni and pure c++ components completely?

[jmazanec15]

Description

Comes as a spin off of #1776. With all of the mocking around the JNI components and running valgrind, I am having trouble to determine what memory issues are related to testing and what are actually functional.

Right now, our JNI functions make calls to library wrappers passing with them a JNIUtil class. The JNI util class provides a layer between the interfaces with pure c++ and the direct JNI calls so that testing and mocking are easier. In other words, the wrapper code will not directly call any jni functions.

However, as a lot of functionality has been added, the tests are getting more difficult to manage as we mix calls for java/c++ conversion with calls to the libraries. For example, see https://github.com/opensearch-project/k-NN/blob/main/jni/src/faiss_wrapper.cpp#L90-L156. This ends up requiring a complex and error prone testing and mocking structure.

I think we can simplify this quite a bit by making a clear separation between the pure c++ and java code. To do this, for our wrapper interfaces, instead of passing JNIUtil, we only pass pure C++ components. For performance reasons, if the component does need to be converted in the function that is being called, as opposed to before the function call (i.e. maybe to avoid a copy), we can pass suppliers and or callbacks that will take care of this instead. Then, we will have a thin jni->cpp layer that will bridge jni calls with pure c++ calls.

Then, the testing of c++ wrappers, which carries the most complexity, can be done in pure C++. For important JNI conversion functionality, we can implement our own mocking and unit tests and then also cover from the Java side tests.