Add Google tests for unit testing jni

[jmazanec15]

Description

This PR adds google tests for testing the nmslib_wrapper and faiss_wrapper. Additionally, I made some minor stylistic changes to the jni to help testing and clean up. The primary purpose of these tests is to be able to identify potential memory leaks.

In order to mock the JNIUtilInterface, this PR adds MockJNIUtil class built off of gmock. In the constructor of this class, the default behavior is defined. This can be overriden inside individual test cases.

While the tests cover each library wrapper function, they do not yet exercise all possible functionality. In order to keep the scope of this PR focused, I will leave expansion to a future PR.

In order to build tests:

// This will produce the test executable in bin/jni_test
cd jni
cmake .
make

To run the tests:

// Run all tests
bin/jni_test

// Run certain tests
bin/jni_test --gtest_filter=<Test filter name (can include *)>

// Run tests a certain number of times
bin/jni_test --gtest_repeat=X

In order to test memory checks, I ran the tests with valgrind. Here are some of the results:

>> valgrind bin/jni_test
...
==28779== LEAK SUMMARY:
==28779==    definitely lost: 0 bytes in 0 blocks
==28779==    indirectly lost: 0 bytes in 0 blocks
==28779==      possibly lost: 336 bytes in 1 blocks
==28779==    still reachable: 124,880 bytes in 10 blocks

>> valgrind bin/jni_test --gtest_repeat=4
...
==28790== LEAK SUMMARY:
==28790==    definitely lost: 0 bytes in 0 blocks
==28790==    indirectly lost: 0 bytes in 0 blocks
==28790==      possibly lost: 336 bytes in 1 blocks
==28790==    still reachable: 124,880 bytes in 10 blocks

>> valgrind bin/jni_test --gtest_filter=Nmslib*
...
==28865== LEAK SUMMARY:
==28865==    definitely lost: 0 bytes in 0 blocks
==28865==    indirectly lost: 0 bytes in 0 blocks
==28865==      possibly lost: 0 bytes in 0 blocks
==28865==    still reachable: 122,888 bytes in 7 blocks

>> valgrind bin/jni_test --gtest_filter=NmslibInit*
...
==28875== LEAK SUMMARY:
==28875==    definitely lost: 0 bytes in 0 blocks
==28875==    indirectly lost: 0 bytes in 0 blocks
==28875==      possibly lost: 0 bytes in 0 blocks
==28875==    still reachable: 122,888 bytes in 7 blocks

>> valgrind bin/jni_test --gtest_filter=Faiss*
...
==28876== LEAK SUMMARY:
==28876==    definitely lost: 0 bytes in 0 blocks
==28876==    indirectly lost: 0 bytes in 0 blocks
==28876==      possibly lost: 336 bytes in 1 blocks
==28876==    still reachable: 2,000 bytes in 4 blocks

A couple things to note about these results:

1. A large chunk of still reachable memory comes from the call to the nmslib initlibrary function. This is okay because it only happens once throughout the lifecycle
2. In the faiss tests, there is some possibly lost and still reachable memory. I need to further investigate this, but will not do so in this PR.

Issues Resolved

#31

Check List

• New functionality includes testing.
  • All tests pass
• New functionality has been documented.
  • New functionality has javadoc added
• Commits are signed as per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[dblock]

This is nice work, I haven't done C/C++ unit testing in a lifetime, great to see how the modern version looks like!

1. A large chunk of still reachable memory comes from the call to the nmslib initlibrary function. This is okay because it only happens once throughout the lifecycle

Without looking at the code you probably want to find a way to start measuring leaked memory after the init call(s), or explicitly call a function that cleans up what's allocated in the init call.

[jmazanec15]

This is nice work, I haven't done C/C++ unit testing in a lifetime, great to see how the modern version looks like!

1. A large chunk of still reachable memory comes from the call to the nmslib initlibrary function. This is okay because it only happens once throughout the lifecycle

Without looking at the code you probably want to find a way to start measuring leaked memory after the init call(s), or explicitly call a function that cleans up what's allocated in the init call.

The way I confirmed was that I ran valgrind just on the init library call and the still reachable memory matched the value returned when I ran valgrind for all of the nmslib tests. In terms of deallocation, the init library function calls registration function like this. There does not appear to be a way to unregister these spaces or methods.

[vamshin]

LGTM! Thanks for adding coverage for c++ code. This also helps with running Valgrind memleak tests.