Move off of our custom JNA build

[jaymode]

This commit switches to the latest version of JNA. We previously built
our own JNA jar with native libraries that supported glibc 2.7 due to a
change by JNA that required glibc 2.14. JNA changed the minimum version
of glibc back to 2.7 in the 4.5 release, so we should not need to build
or use a custom jar.

Relates #23640

[elasticmachine]

Pinging @elastic/es-core-infra

[rjernst]

I'm torn on this. When adding the custom jna build, we found that jna's build process was as far from reproducible as possible (relying on random developers producing the build on various systems). I don't trust that a future version wouldn't have similar problems.

Additionally, our custom build reduces the platforms' binary files included within the jar to those we support. The purpose was to limit to those platforms we officially support, since otherwise we would need a complicated build to produce all the various systems supported by jna.

My main concern is we might have to do this again in the future, and we would then be flip-flopping for which platforms jna works on.

[mark-vieira]

we found that jna's build process was as far from reproducible as possible (relying on random developers producing the build on various systems)

Ignorance is bliss here unfortunately 😉. An embarrassing number of popular libraries hosted in places like Maven Central are in the same boat. I'm not sure this alone is a compelling reason to build stuff ourself. As long as the concrete version is a stable binary, we've tested it, and it works I think that's a safe call.

I'm generally 👍 to ditching any customer forks/distributions of freely available published libraries unless there is a strong compelling argument otherwise. If the latest version meets our needs I'm in favor of ditching our custom build in favor of it.

[jasontedor]

An embarrassing number of popular libraries hosted in places like Maven Central are in the same boat.

Yes, this might be the case for other projects, but we know it’s the case for JNA. Instead we are building JNA tailored exactly to the OS that we support, which is important to us two fold:

• to ensure that our distributions support those that we claim to support
• to keep it clear that other distributions are not supported; this is an important distinction since JNA includes native binaries for platforms that we don’t support

[jaymode]

Thanks for the details @rjernst @jasontedor.

I'd still like for us to move off of our own build but it looks like we would probably want upstream to have a few things in place prior to doing so such as a build process that is reproducible and publishing separate artifacts so that we would only need to pull in those for architectures we support. I will close this for now and start a conversation upstream to see if this would be something they are interested in.