[Feature] Standardize system-test node lifecycle management via trond

[warku123]

Summary

Currently the system-test CI starts a java-tron FullNode by inlining `nohup java -jar` directly in the GitHub Actions workflow, with the node config hardcoded in this repository. This proposal introduces `trond` (TRON's declarative node deployment CLI) as the standard way to bring up and tear down the stest single-SR private chain, while keeping a full fallback path so CI never breaks due to trond availability issues.

Problem

Motivation

The stest workflow needs a reproducible, maintainable way to start a single-SR private chain against which the 649 testcases run. As java-tron evolves, node configuration (ports, genesis witnesses, resource limits) tends to drift and requires manual edits scattered across multiple places.

Current State

Node startup is handled entirely inside `.github/workflows/system-test.yml` via an inline shell block. The HOCON config (`config-system-test.conf`) lives in `testcase/src/test/resources/` and is copied by the workflow before launch. There is no dedicated teardown step — the GHA runner is discarded after each run, so leftover processes are never explicitly cleaned up.

Limitations or Risks

• Config drift: node configuration is maintained in two places (this repo's `config-system-test.conf` and the intent schemas in tron-deployment), and they can diverge silently.
• No structured teardown: in local or self-hosted runner environments, dangling processes block ports for subsequent runs.
• Hard to extend: adding a second node, changing resource limits, or switching from jar to Docker requires editing the raw workflow YAML.

Proposed Solution

Proposed Design

Introduce two scripts — `scripts/stest-up.sh` and `scripts/stest-down.sh` — as a thin bridge between the java-tron CI and trond:

• `stest-up.sh` downloads the latest stable `trond` release from GitHub Releases, installs the bundled `system-test-singlenode-intent.yaml`, places the caller-supplied `FullNode.jar` at the expected install path, then runs `trond config validate` → `trond preflight` → `trond apply` → `trond verify` to bring the node up under systemd.
• `stest-down.sh` tears down the node via `trond network destroy` / `systemctl stop` and removes the install path. It always exits 0 so it is safe to call from a `if: always()` CI step.

The scripts carry a two-layer fallback to ensure CI never regresses:

1. Script-layer fallback: if trond cannot be downloaded (no stable release yet, network issue, or `STEST_FORCE_FALLBACK` is set), `stest-up.sh` falls back to the current `nohup java -jar` approach using `config-system-test.conf` from this repo. Behavior is identical to the current CI.
2. Workflow-layer fallback: if the checked-out system-test branch does not contain `stest-up.sh` at all, the java-tron workflow detects this and executes the inline startup logic directly.

The `system-test` network HOCON template that trond uses is defined and maintained in `tronprotocol/tron-deployment` (tronprotocol/tron-deployment#170), keeping node configuration in a single canonical location.

Key Changes

• `scripts/stest-up.sh` (new): two-mode node startup (trond preferred, nohup fallback)
• `scripts/stest-down.sh` (new): structured teardown, safe for `if: always()`
• `tronprotocol/tron-deployment` feat(config): add system-test as fourth embedded HOCON network template tron-deployment#170: `system-test` embedded HOCON network template
• `tronprotocol/tron-deployment` ci(release): fix goreleaser pipeline and enable fork-friendly releases tron-deployment#171: automated goreleaser release pipeline — a prerequisite for this feature, since `stest-up.sh` downloads `trond` from `releases/latest`. Beyond stest, this also makes trond available as a standalone tool that operators can install directly from GitHub Releases to manage their own TRON nodes.
• `tronprotocol/java-tron`: `system-test.yml` updated to call `stest-up.sh` / `stest-down.sh` instead of inline shell

Impact

• Developer experience: node lifecycle is declarative and reproducible; config lives in one place.
• Stability: structured teardown prevents port conflicts in self-hosted or local environments.
• CI safety: dual fallback guarantees the test suite continues running even during the trond rollout period.
• No impact on test logic: testcases connect to the same ports (`8090 / 50051 / 8545 / 18888`) regardless of which startup mode is active.

Compatibility

• Breaking Change: No
• Default Behavior Change: No — fallback mode produces an identical node for the test suite
• Migration Required: No — the workflow-layer fallback handles the transition automatically

References

• feat(config): add system-test as fourth embedded HOCON network template tron-deployment#170: system-test HOCON template
• ci(release): fix goreleaser pipeline and enable fork-friendly releases tron-deployment#171: goreleaser release pipeline — enables `trond` binary distribution via GitHub Releases, serving both the stest automation use case and end users who want to manage TRON nodes with trond directly
• `scripts/README.md` in `feat/trond-bridge` branch: usage instructions for stest-up/down

Additional Notes

• Do you have ideas regarding implementation? Yes
• Are you willing to implement this feature? Yes — implementation is ready on branch `warku123:feat/trond-bridge` (system-test) and `warku123:feat/system-test-trond` (java-tron), pending tron-deployment PRs merging first.