HDDS-13275. Improve CheckNative implementation

[adoroszlai]

What changes were proposed in this pull request?

Simplify CheckNative implementation, reducing duplication.

Also improve output a bit by align columns.

https://issues.apache.org/jira/browse/HDDS-13275

How was this patch tested?

Without any native lib:

$ hadoop-ozone/dist/target/ozone-2.1.0-SNAPSHOT/bin/ozone debug checknative                                                               
Native library checking:
     hadoop:  false  
      ISA-L:  false  hadoop native library cannot be loaded.
    OpenSSL:  false  
rocks-tools:  false  

With Hadoop 3.4.1:

$ LD_LIBRARY_PATH=~/tmp/hadoop-3.4.1/lib/native:$LD_LIBRARY_PATH hadoop-ozone/dist/target/ozone-2.1.0-SNAPSHOT/bin/ozone debug checknative
Native library checking:
     hadoop:  true   ~/tmp/hadoop-3.4.1/lib/native/libhadoop.so.1.0.0
      ISA-L:  false  Loading ISA-L failed: Failed to load libisal.so.2 (libisal.so.2: cannot open shared object file: No such file or directory)
    OpenSSL:  false  Cannot load libcrypto.so (libcrypto.so: cannot open shared object file: No such file or directory)!
rocks-tools:  false  

With Ozone native lib (after build with -Drocks_tools_native):

Native library checking:
     hadoop:  false  
      ISA-L:  false  hadoop native library cannot be loaded.
    OpenSSL:  false  
rocks-tools:  true   libozone_rocksdb_tools.so

With both:

Native library checking:
     hadoop:  true   ~/tmp/hadoop-3.4.1/lib/native/libhadoop.so.1.0.0
      ISA-L:  false  Loading ISA-L failed: Failed to load libisal.so.2 (libisal.so.2: cannot open shared object file: No such file or directory)
    OpenSSL:  false  Cannot load libcrypto.so (libcrypto.so: cannot open shared object file: No such file or directory)!
rocks-tools:  true   libozone_rocksdb_tools.so

CI:
https://github.com/adoroszlai/ozone/actions/runs/15652247805

[jojochuang]

LGTM

[adoroszlai]

Thanks @jojochuang for reviewing and merging this.

[peterxcli]

Thanks for this refactoring! I have one quick question left inline.

[peterxcli]

Was there a specific reason for using Object instead of String? Are you planning to return different types in future iterations?

    ...
    Map<String, String> results = new LinkedHashMap<>();
    ...

  private static String checkLibrary(boolean loaded, Supplier<String> libraryName) {
    return checkLibrary(loaded ? null : "", libraryName);
  }
  
  private static String checkLibrary(String failureReason, Supplier<String> libraryName) {
    boolean loaded = failureReason == null;
    String detail = loaded ? libraryName.get() : failureReason;
    return String.format("%-5b  %s", loaded, detail);
  }

[adoroszlai]

Was there a specific reason for using Object instead of String? Are you planning to return different types in future iterations?

I had exactly that in mind, although currently I don't plan to. I thought there is no downside as opposed to limiting the map to String values.