Ensure we can load the native library or fail the build

[normanmaurer]

Motivation:

We used assumeTrue(...) in some places before to detect if we could load the native library but this could lead to the sitation that we not notice if we break native loading.

Modifications:

Always fail if we cant load the native library

Result:

Ensure we not cause any regression in the native loading code in the future

[normanmaurer]

/cc @violetagg also related to your PR... This will ensure we not get into trouble again later on.

[fredericBregier]

@normanmaurer Maybe not related, maybe only due to "latency" of Maven repositories, but when I update just few minutes ago to the last version of Netty (4.1.64), in my dependencies, I've got the netty native library (2.0.39), I've got an issue on cannot find depdencies such as the following.

Could not resolve dependencies for...: The following artifacts could not be resolved:

• io.netty:netty-tcnative:jar:${os.detected.classifier}:2.0.39.Final
• io.netty:netty-transport-native-epoll:jar:${os.detected.name}-${os.detected.arch}:4.1.64.Final
  Could not find artifact io.netty:netty-tcnative:jar:${os.detected.classifier}:2.0.39.Final

I'm on Linux x64 (Ubundu based).
I will retest tomorrow morning, just in case it was only the latency on maven repositories.

[fredericBregier]

@normanmaurer I will retry tomorrow, but just for note:

• using 4.1.63-Final : dependecies are OK, including netty-tcnative version 2.0.39
• using 4.1.64-Final: depdencies are KO, blocking on netty-tcnative version 2.0.39, like ${os.detected.classifier} is not resolved, neither io.netty:netty-transport-native-epoll:jar:${os.detected.name}-${os.detected.arch}:4.1.64.Final, like ${os.detected.name}-${os.detected.arch} not resolved too

[normanmaurer]

@fredericBregier can you show me your pom.xml file ?

[fredericBregier]

@normanmaurer I opened an issue with a simple pom.xml with only Netty dependencies (no code, just a pom.xml) #11272
I can confirm that using 4.1.63 is ok, while 4.1.64 is ko.