fix(plugins): exclude transitive leveldbjni-all from :crypto

[barbatos2011]

Summary

x86_64 builds of Toolkit.jar since #6637 throw NoSuchMethodError on org.iq80.leveldb.Options.maxBatchSize(I) when running commands such as db archive / --rebuild-manifest:

Exception in thread "main" java.lang.NoSuchMethodError:
  org.iq80.leveldb.Options.maxBatchSize(I)Lorg/iq80/leveldb/Options;
    at org.tron.plugins.DbArchive$ArchiveManifest.newDefaultLevelDbOptions(DbArchive.java:137)
    ...

This PR fixes the root cause and adds CI smoke tests so the same class of bug cannot reach a release artifact again.

Why

#6637 introduced implementation(project(":crypto")) to the plugins module without excluding org.fusesource.leveldbjni:leveldbjni-all, which :crypto pulls in transitively via :common -> :platform. The direct :platform dependency in plugins/build.gradle already excludes leveldbjni-all (so the TRON-fork io.github.tronprotocol:leveldbjni-all:1.18.2 can be used instead), but the new transitive path through :crypto does not. The result on x86 is two jars carrying org/iq80/leveldb/Options.class on the runtime classpath:

• org.fusesource.leveldbjni:leveldbjni-all:1.8 — does NOT have Options.maxBatchSize(int)
• io.github.tronprotocol:leveldbjni-all:1.18.2 — DOES have Options.maxBatchSize(int)

:plugins:dependencyInsight confirms the regression path:

org.fusesource.leveldbjni:leveldbjni-all:1.8
\--- project :platform
     +--- runtimeClasspath
     \--- project :common
          \--- project :crypto
               \--- runtimeClasspath

Why tests didn't catch it

• :plugins:test keeps source jars separate; the JVM classloader returns the first match in classpath order, which is 1.18.2 (declared directly by plugins/build.gradle). Tests pass.
• The fat-jar binaryRelease task merges class entries with last-write-wins (Gradle Zip default INCLUDE), so the surviving Options.class can be the 1.8 copy. Same classpath, opposite winner.
• ARM64 declares only :platform directly (no 1.18.2 fork), so there is no conflict; ARM64 also excludes Archive tests.
• The CI matrix builds the fat jar but never executes it — Toolkit-specific runtime errors are not exercised.

Fix

1. plugins/build.gradle — exclude org.fusesource.leveldbjni:leveldbjni-all from the :crypto dependency, mirroring the existing exclusion on the direct :platform dependency. This collapses the x86 runtimeClasspath to a single leveldbjni-all (1.18.2).
2. .github/workflows/pr-build.yml — after each platform build (macos / ubuntu-arm / rockylinux-x86 / debian11-x86), run a short smoke test against the freshly built Toolkit.jar:

   java -jar Toolkit.jar help
   java -jar Toolkit.jar db --help
   java -jar Toolkit.jar db archive -h     # directly exercises the failing path
   java -jar Toolkit.jar keystore --help   # exercises the :crypto path added by #6637
   

   Each smoke step adds ~10–15s; jobs run in parallel so PR critical path increases by at most ~15s.

Verification

Reproduced on x86_64 + JDK 8 in eclipse-temurin:8-jdk (clean build):

• Before fix: java -jar Toolkit.jar db archive -d <empty> → NoSuchMethodError
• After fix: java -jar Toolkit.jar db archive -d <empty> → exits 0, reports "directory does not contain any database"
• :plugins:dependencies --configuration runtimeClasspath no longer lists org.fusesource.leveldbjni:leveldbjni-all:1.8
• ./gradlew checkstyleMain checkstyleTest passes
• ./gradlew :plugins:test passes (KeystoreUpdate, DbLite, RocksDb tests)

Test plan

• CI passes on all four platform builds
• New "Toolkit jar smoke test" step is green on each platform
• Reviewer manually confirms java -jar Toolkit.jar db archive -d <db> works on x86 with this branch's artifact

Notes

• No production Java changes; only plugins/build.gradle (+6 lines) and .github/workflows/pr-build.yml (+36 lines).
• ARM64 path is unaffected: the :platform direct dependency on ARM64 has no exclusion (it never had the conflict), and the new :crypto exclusion is a no-op there.
• The two org/iq80/leveldb/Options.class entries that still exist in the fat jar (from leveldbjni-all:1.18.2 uber and leveldb-api:1.18.2 standalone) are pre-existing and harmless because both are the same 1.18.2 version with maxBatchSize available.

[halibobo1205]

The fix itself is correct, but the excludes aren't aligned.

Two ways to make this consistent — pick one:

• A. Add the other two excludes on :crypto — if plugins should NOT bundle zksnark / commons-io.
• B. Remove the other two excludes on :platform — if plugins actually NEEDS zksnark / commons-io.

[barbatos2011]

Good catch — verified via :plugins:dependencyInsight that both zksnark-java-sdk and commons-io were indeed leaking through :crypto -> :common -> :platform. Went with option A to preserve the existing :platform exclusion intent. Pushed 69d7f2156 aligning all three excludes on :crypto. Re-verified on x86_64 + JDK 8: runtimeClasspath no longer contains any of the three, smoke still passes.

[barbatos2011]

Update: option A worked for leveldbjni-all but broke :plugins:test on x86_64 (rockylinux CI just failed). DbLiteTest boots a Spring context that loads ZksnarkInitService, which actually pulls in classes from both commons-io (FileUtils) and zksnark-java-sdk (LibrustzcashWrapper) at runtime. Once both :platform and :crypto excluded those two, x86 testRuntimeClasspath lost them entirely (ARM64 was fine because the ARM branch declares :platform without excludes).

So the :platform-side excludes for zksnark and commons-io are deduplication, not a 'kept out of plugins' intent — the artifacts must keep arriving via :crypto -> :common -> :platform. Reverted those two in 320da62c3 and added a comment explaining why the asymmetry is intentional. leveldbjni-all remains mirrored because that one is the actual classpath conflict. :plugins:test passes again on x86 docker and smoke is still green.

[halibobo1205]

The binaryRelease task in plugins/build.gradle declares

dependsOn (project(':protocol').jar, project(':platform').jar)

but its body consumes outputs from :crypto:jar and :common:jar via runtimeClasspath. Gradle prints an implicit_dependency warning and disables execution optimizations to compensate; under parallel / incremental / partial-build scenarios this can lead to the fat jar being assembled before :crypto:jar or :common:jar is up-to-date, producing broken artifacts or build failures. Future Gradle versions will likely promote this to a hard error.

Recommend adding project(':crypto').jar and project(':common').jar to the dependsOn list.

The log

> Task :plugins:buildToolkitJar
Execution optimizations have been disabled for task ':plugins:buildToolkitJar' to ensure correctness due to the following reasons:
  - Gradle detected a problem with the following location: '/Users/boson/IdeaProjects/java-tron/crypto/build/libs/crypto-1.0.0.jar'. Reason: Task ':plugins:buildToolkitJar' uses this output of task ':crypto:jar' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.6.4/userguide/validation_problems.html#implicit_dependency for more details about this problem.
  - Gradle detected a problem with the following location: '/Users/boson/IdeaProjects/java-tron/common/build/libs/common-1.0.0.jar'. Reason: Task ':plugins:buildToolkitJar' uses this output of task ':common:jar' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.6.4/userguide/validation_problems.html#implicit_dependency for more details about this problem.

[barbatos2011]

Confirmed locally — ./gradlew clean && ./gradlew :plugins:buildToolkitJar immediately fails with Cannot expand ZIP '.../crypto/build/libs/crypto-1.0.0.jar', exactly as you predicted. Pushed 0aebaffb3 adding :crypto:jar and :common:jar to the dependsOn list. After the fix the same command builds clean with --warning-mode all and no implicit_dependency warning. Thanks for catching this.

[halibobo1205]

Maybe exclude just for x86_64?
pre :platform

    if (rootProject.archInfo.isArm64) {
        testRuntimeOnly group: 'org.fusesource.hawtjni', name: 'hawtjni-runtime', version: '1.18' // for test
        implementation project(":platform")
    } else {
        implementation project(":platform"), {
            exclude(group: 'org.fusesource.leveldbjni', module: 'leveldbjni-all')
            exclude(group: 'io.github.tronprotocol', module: 'zksnark-java-sdk')
            exclude(group: 'commons-io', module: 'commons-io')
        }
        implementation 'io.github.tronprotocol:leveldbjni-all:1.18.2'
        implementation 'io.github.tronprotocol:leveldb:1.18.2'
    }

[barbatos2011]

Good call — applied in 26f463b72. Wrapped the leveldbjni-all exclude on :crypto in if (!rootProject.archInfo.isArm64) to mirror the existing arch split on the :platform-direct declaration. Behavior is preserved (ARM64 still resolves leveldbjni-all 1.8 via :platform direct; x86 still resolves only the io.github.tronprotocol 1.18.2 fork) and the comment now reads as 'this fix is x86-specific' rather than a generic policy. Verified :plugins:test and the Toolkit smoke on both arches.