Add GraalVM Reachability Metadata and corresponding nativeTest for Seata integration

[linghengqian]

For #29052.

Changes proposed in this pull request:

• Add GraalVM Reachability Metadata and corresponding nativeTest for Seata integration.
• Uses io.seata:seata-all:1.8.0 and make corresponding adjustments in nativeTests. Before Add GraalVM Reachability Metadata and corresponding nativeTest for Seata integration #30138 (comment) , using Seata Client under GraalVM Native Image requires using the version released under its 1.x branch. Using io.seata:seata-all:2.0.0 under nativeTest needs to wait for the ByteBuddy Java API to be removed on the seata side.
• Affected by Cast issue when bumping from 0.9.28 to 0.10.0 graalvm/native-build-tools#572, updates documentation for the GraalVM Native Image for Gradle projects building ShardingSphere JDBC Core.
• Since [Bug]: Using org.testcontainers:mysql will report an error as mysqld failed while attempting to check config in GraalVM Native Image testcontainers/testcontainers-java#7954 has not been closed yet, to simplify understanding, let us temporarily switch the database used by Seata-integrated nativeTest from MySQL to Postgresql.
• Seata's configuration file file.conf has no dynamically defined Java API, which prevents the integration of testcontainers. We may have to hardcode the port on the host when creating the testcontainers-java container.
• When using io.seata:seata-all:2.0.0, involving an undocumented bug in the Tracing Agent of GraalVM CE 23.1.2 For JDK 21.0.2, reported below when configuration->agent->options->enableExperimentalPredefinedClasses of GraalVM Native Build Tools is set to true. This is not caused by insufficient memory, but more like a design issue of GraalVM CE. Refer to [GR-52650] When experimental-class-define-support=true's buildArg is passed to GraalVM Tracing Agent, incorrect Conditional Metadata is generated oracle/graal#8396 .

[INFO] Results:
[INFO] 
[INFO] Tests run: 14, Failures: 0, Errors: 0, Skipped: 0
[INFO] 
[WARNING] Corrupted channel by directly writing to native stream in forked JVM 1. See FAQ web page and the dump file /home/linghengqian/TwinklingLiftWorks/git/public/shardingsphere/test/native/target/surefire-reports/2024-02-15T23-36-35_487-jvmRun1.dumpstream
[INFO] 
[INFO] --- native-maven-plugin:0.10.0:merge-agent-files (test-native) @ shardingsphere-test-native ---
[INFO] Merging agent 1 files into /home/linghengqian/TwinklingLiftWorks/git/public/shardingsphere/test/native/target/native/agent-output/test
[INFO] 
[INFO] --- native-maven-plugin:0.10.0:test (test-native) @ shardingsphere-test-native ---
[INFO] Skipping native-image tests (parameter 'skipTests' or 'skipNativeTests' is true).
[INFO] 
[INFO] --- native-maven-plugin:0.10.0:metadata-copy (default-cli) @ shardingsphere-test-native ---
[INFO] Found GraalVM installation from JAVA_HOME variable.
[INFO] Copying files from: test
[ERROR] Metadata copy process failed with code: 1

---

Before committing this PR, I'm sure that I have checked the following options:

• My code follows the code of conduct of this project.
• I have self-reviewed the commit code.
• I have (or in comment I request) added corresponding labels for the pull request.
• I have passed maven check locally : ./mvnw clean install -B -T1C -Dmaven.javadoc.skip -Dmaven.jacoco.skip -e.
• I have made corresponding changes to the documentation.
• I have added corresponding unit tests for my changes.

[slievrly]

For #29052.

Changes proposed in this pull request:

• Add GraalVM Reachability Metadata and corresponding nativeTest for Seata integration.
• Remove inappropriate reference to com.mysql.cj.jdbc.exceptions.CommunicationsException.
• Uses io.seata:seata-all:1.7.1 and make corresponding adjustments in nativeTests. Before merging feature: First support native-image for seata-client incubator-seata#5234, using Seata Client under GraalVM Native Image requires using the version released under its native branch. Using io.seata:seata-all:2.0.0 under nativeTest needs to wait for the ByteBuddy Java API to be removed on the seata side.

Seata 1.x supports native image from version 1.7.0, refer to the merged PR apache/incubator-seata#5476 (comment). Currently, 2.x does not support native image, and this function of 1.x will be translated in the future. For native image integration, I recommend using 1.8.0, the latest version of 1.x.

• seata's configuration file file.conf has no dynamically defined Java API, which prevents the integration of testcontainers.

The client-side uses the Seata SDK, which can depend on Seata in two ways:

1. By using seata-all.jar, it will read registry-$env.conf (with the default value being registry.conf), which defines how Seata accesses the metadata from the registry and configuration centers. When config.type=xxx is read from the configuration center and xxx is set to 'file', it will by default read the configuration from file.conf located in the same directory (though other paths and filenames can be specified). This does not support dynamic refresh of the configuration. When xxx is set to a third-party configuration center, some configurations support dynamic refresh, but most configurations are read-once types during startup. Currently, it does not support using Java API to modify configurations and reload them directly.

2. By using seata-spring-boot-starter.jar. This defaults to including seata-all.jar dependency and adds autoconfiguration features for Spring Boot. It supports directly using Spring Boot's configuration files (either properties or yml) for configuration. Refer to https://github.com/apache/incubator-seata/tree/2.x/script/client/spring for examples. You can consider storing these configurations in your application's configuration center, where some configurations support dynamic refresh. Likewise, it does not support using Java API to modify configurations and reload them directly.

Furthermore, the priority of Seata client configuration is ENV (System.getenv()) > -D (System.getProperty()) > file or configuration center. You can consider injecting environment variables in testContainer.

[funky-eyes]

Is this the problem you're having? raphw/byte-buddy#1588

[linghengqian]

Is this the problem you're having? raphw/byte-buddy#1588

• This is reasonable because using bytebuddy under GraalVM Native Image requires collecting additional JSON entries in the buildArg with experimental-class-define-support=true enabled. In raphw's github gist use case, I gave an example of using the Gradle Plugin implementation of GraalVM Native Build Tools to collect these files. Refer to the following link,

  • https://gist.github.com/raphw/e0f6864ddcad69630d839c2eebaad818?permalink_comment_id=4444676#gistcomment-4444676
  • https://gist.github.com/raphw/e0f6864ddcad69630d839c2eebaad818
  • https://github.com/graalvm/native-build-tools/blob/0.10.0/common/utils/src/main/java/org/graalvm/buildtools/agent/AgentConfiguration.java#L96

• In my opinion, those files are too large to be saved in multi-person collaboration git, so I did not discuss them in the current PR. I just opened an issue on the GraalVM side for a bug related to this experimental feature. Reference [GR-52650] When experimental-class-define-support=true's buildArg is passed to GraalVM Tracing Agent, incorrect Conditional Metadata is generated oracle/graal#8396 .

• 

• The main reason the current PR is still in draft is that it contains some unrelated changes, which have been broken down into Bump io.seata:seata-all for testing to 2.0.0 #30146 and Fixes ClassPathURLLoader cannot find files under GraalVM Native Image #30145.

• The current PR also contains some significant violations of the best practices defined by testcontainers-java, which require additional investigation.

[linghengqian]

• Even if the free local port is dynamically found through Java API code, file.conf still needs to be dynamically created after passing it to the Java API of testcontainers-java, which seems to break some of the conventions of GraalVM Native Image to a certain extent.
• I'm worried about encountering insufficient Unix permissions like io.etcd.jetcd.launcher.EtcdContainer -- Error deleting directory when using jetcd-tests on unit-testing. etcd-io/jetcd#1310 . testcontainers-java always expects to use operating system-specific FileSystem like sun.nio.fs.UnixFileSystem/file:/resources/{entry}, but in fact we can only use com.oracle.svm.core.jdk.resources.NativeImageResourceFileSystem/resource:file:/resources/{entry} in NativeTest .
• I don't think this is where application.yml should be introduced, although we can use a separate Spring Boot bootstrap class in a separate class.
• This is mainly because this requires the introduction of org.springframework.boot:spring-boot-maven-plugin to use the Maven Goal of process-test-aot, which I think complicates things to a certain extent, because it seems best to have a module like shardingsphere-test-native-spring-boot-starter to additionally define a Maven Profile for writing nativeTest.
• As a temporary measure, this unit test uses the hard-defined port 39567 and is restricted to running under Native Image only because it involves the creation of the Docker Image testcontainers/ryuk. Let me explore later what APIs are available on the Seata side that can be extended.