fix zstd on windows

Sandboxing on Windows is more limited than on other platforms, so two jni_md.h headers were ending up in the include path.  This resulted in the wrong jni_md.h header being used on Windows, which meant that the JNIEXPORT macro was not being set to actually export symbols appropriately on Windows.  This caused any attempts to use zstd on windows, whether for http_archive, gRPC cache compression, etc. to result in an UnsatisfiedLinkError being thrown.

Change to use a similar method as the main bazel jni stuff, which is to copy the jni.h and jni_md.h headers over.  This prevents accidentally picking up a header from the wrong architecture.

Relates to bazelbuild#16041

Closes bazelbuild#16293.

PiperOrigin-RevId: 475839895
Change-Id: Ia5569c50c8764699abe9858207a256b921980b92

.bazelci/postsubmit.yml

@@ -249,7 +249,7 @@ tasks:
       - "-//src/test/java/com/google/devtools/build/lib/versioning/..."
       - "-//src/test/java/com/google/devtools/build/lib/rules/java/..."
       - "-//src/test/java/com/google/devtools/build/lib/worker/..."
-      - "-//src/test/java/com/google/devtools/build/lib/remote/..."
+      - "-//src/test/java/com/google/devtools/build/lib/remote:remote"
       - "-//src/test/shell/bazel/remote/..."
       - "-//tools/python:pywrapper_test"
     include_json_profile:

.bazelci/presubmit.yml

@@ -241,8 +241,6 @@ tasks:
       - "-//src/test/java/com/google/devtools/build/lib/rules/java/..."
       - "-//src/test/java/com/google/devtools/build/lib/worker/..."
       - "-//src/test/java/com/google/devtools/build/lib/remote:remote"
-      # disable zstd test on Windows due to unsatisfied link error. https://github.com/bazelbuild/bazel/issues/16041
-      - "-//src/test/java/com/google/devtools/build/lib/remote/zstd/..."
       - "-//src/test/shell/bazel/remote/..."
       - "-//tools/python:pywrapper_test"
   rbe_ubuntu1804: