fix(java): initialize netty-shaded at run-time and add reflection configurations for netty classes

[mpeddada1]

Build initialization of netty causes inconsistent behavior when an application is run locally versus on Cloud Run. One such case as discovered in https://github.com/mutianf/graalvm-test is when a bigtable application works fine with native image compilation locally but times out on Cloud Run.

More details:
Netty System.nanoTime() as a memoized static start_time variable when the native image is being built. System.nanoTime() is an arbitrary value and platform specific so when the start_time is compared against another System.nanoTime() at run time on the container, the comparison may not always be consistent. Netty is initialized at native image build time by default for netty 4.x but we can adjust this by setting --initialize-at-run-time=io.grpc.netty.shaded.io.netty in a META-INF/native-image/native-image.properties file.

Additionally, build time initialization of netty also causes build time issues when third party logging libraries like SLF4J are used:

Fatal error: com.oracle.graal.pointsto.util.AnalysisError$ParsingError: Error encountered while parsing io.grpc.netty.shaded.io.netty.util.internal.SystemPropertyUtil.getBoolean(java.lang.String, boolean)
Parsing context:
   at io.grpc.netty.shaded.io.netty.util.internal.SystemPropertyUtil.getBoolean(SystemPropertyUtil.java:96)
   at io.grpc.netty.shaded.io.netty.channel.epoll.Epoll.<clinit>(Epoll.java:33)
   at org.graalvm.nativeimage.pointsto/com.oracle.graal.pointsto.util.AnalysisError.parsingError(AnalysisError.java:153)
...
java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165)
Caused by: com.oracle.graal.pointsto.constraints.UnsupportedFeatureException: No instances of org.slf4j.jul.JDK14LoggerAdapter are allowed in the image heap as this class should be initialized at image runtime. To see how this object got instantiated use --trace-object-instantiation=org.slf4j.jul.JDK14LoggerAdapter.

It is important to note that this may result in a performance cost depending on the code path the application follows but given the persistence of these issues as a result of build-time netty initialization, run-time initialization of netty provides a more out-of-the-box experience.

[mpeddada1]

The downstream checks are failing due to:

Failed to execute goal on project google-cloud-kms: Could not resolve dependencies for project com.google.cloud:google-cloud-kms:jar:2.13.0-SNAPSHOT: Could not find artifact com.google.cloud:google-cloud-core:jar:2.9.5-SNAPSHOT in google-maven-central-copy (https://maven-central.storage-download.googleapis.com/maven2) -> [Help 1]
[ERROR] Failed to execute goal on project google-cloud-os-login: Could not resolve dependencies for project com.google.cloud:google-cloud-os-login:jar:2.9.0-SNAPSHOT: com.google.cloud:google-cloud-core:jar:2.9.5-SNAPSHOT was not found in https://maven-central.storage-download.googleapis.com/maven2 during a previous attempt. This failure was cached in the local repository and resolution is not reattempted until the update interval of google-maven-central-copy has elapsed or updates are forced -> [Help 1]

[sonarcloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

0.0% Coverage
0.0% Duplication