fix(docker): improve tooling reliability and deployment safety

[3for]

What does this PR do?

This PR improves and hardens the Docker tooling and documentation for java-tron.

• Aligns the amd64 and ARM64 Dockerfiles with the maintained tron-docker build definitions.
• Preserves the standalone docker.sh workflow, allowing users to download only the script and build an image.
• Makes Dockerfile selection and build context independent of the current working directory.
• Removes the unused docker-entrypoint.sh wrapper and starts FullNode directly.
• Improves argument parsing, validation, quoting, error reporting, and exit codes.
• Uses exact image and container matching instead of ambiguous text searches.
• Publishes mainnet P2P over both TCP and UDP while binding HTTP and gRPC APIs to localhost by default.
• Makes private mode suitable for a local single-node development network by loading the private configuration and enabling witness mode.
• Keeps private P2P, JSON-RPC, and other nonessential ports unpublished by default; multi-machine private networks can expose them explicitly with custom -p options.
• Downloads the private network configuration only when absent, preserves local changes, supports explicit refresh with --update-config true, and fails safely if the download fails.
• Validates --run arguments before pulling or inspecting images.
• Removes unnecessary TTY allocation from background and log commands.
• Adds lightweight, path-filtered Docker static checks for Bash syntax, ShellCheck, and both Dockerfiles.
• Updates docker.md and quickstart.md to document build sources, image tags, port exposure, persistence, lifecycle operations, architecture requirements, production JVM and hardware guidance, and the intended scope of docker.sh.

Why are these changes required?

The previous Docker workflow contained several functional, security, and documentation inconsistencies:

• Docker builds depended on the caller’s current directory and could select the wrong Dockerfile or build context.
• Some invalid arguments, missing dependencies, and malformed invocations could be ignored or return a successful exit status.
• Image and container detection used ambiguous matching.
• Mainnet P2P UDP was not published, while APIs were exposed on all host interfaces.
• Private mode used ports that did not match its configuration and did not enable witness mode.
• Publishing the private witness P2P port by default could expose development credentials and the local private chain to untrusted peers.
• Configuration downloads could overwrite local changes or report failures inconsistently.
• Shell string concatenation could incorrectly split paths or arguments containing spaces or wildcard characters.
• The entrypoint persisted the complete FullNode command line, potentially retaining sensitive arguments in the container layer.
• The documentation did not clearly distinguish Docker Hub images, remote-source local builds, production deployment, single-node private development, and multi-node private networks.
• Docker-related changes had no dedicated, low-cost CI validation.

The revised design intentionally keeps docker.sh as a lightweight helper for common single-container workflows. Advanced production requirements—including custom JVM settings, storage layouts, multiple instances, SR deployment, and multi-node private networks—remain explicit Docker or dedicated deployment-tool workflows.

This PR has been tested by:

• Unit Tests
  • No Java unit tests were required because the changes are limited to Docker scripts, Dockerfiles, CI configuration, and documentation.
• Manual Testing
  • Validated docker/docker.sh with bash -n.
  • Validated docker/docker.sh with ShellCheck.
  • Validated both amd64 and ARM64 Dockerfiles with docker buildx build --check.
  • Verified mainnet and private-network default port mappings.
  • Verified that custom -p, -v, and -c arguments are preserved safely.
  • Verified that invalid or incomplete arguments fail before image lookup or download.
  • Verified private configuration reuse, explicit refresh, failure handling, and stderr output.
  • Verified that git diff --check reports no whitespace errors.

Follow up

• Consider pinning remote source revisions, base-image digests, and released image tags to immutable references where reproducible builds are required.
• Runtime Docker integration tests may be added later if the additional CI cost is justified.
• Advanced deployment features such as arbitrary JVM options, multiple named instances, SR key management, and multi-node orchestration should remain outside the lightweight helper or be handled by dedicated tooling.

Extra details

• docker.sh --build builds from the configured remote java-tron source rather than the caller’s current checkout.
• docker.sh --pull uses the configured Docker Hub image and tag; it may therefore produce a different revision from --build.
• Mainnet HTTP and gRPC endpoints bind to localhost by default, while mainnet P2P remains externally reachable over TCP and UDP.
• Private mode defaults to a local single-node development environment. HTTP and gRPC bind to localhost, while P2P 16666 and JSON-RPC 8545 are not published unless explicitly requested.
• Existing containers retain their original port mappings and must be removed and recreated to adopt the new defaults.
• The Docker CI intentionally remains static-only to avoid materially increasing the total CI runtime.

[warku123]

[Important] run() lacks a container-existence pre-check — a second --run fails with a raw Docker name conflict

docker run -d --name "$CONTAINER_NAME" runs unconditionally. If the container already exists (previous --run, or a rerun after reconfiguring), Docker aborts with a raw Conflict. The container name "/tronprotocol-java-tron" is already in use error and the user has to figure out cleanup themselves. This is a common, always-reachable failure and works against this PR's reliability goal.

Suggestion: before the docker run, reuse the existing docker_container_exists() helper (already used by --start/--stop/--rm) and print a clear message, e.g.:

Container tronprotocol-java-tron already exists. Use --rm to remove it first, or --start to start it.

[3for]

@warku123 Good catch, thanks! Fixed in 305bb06 by checking whether the container already exists before running docker run, using the existing docker_container_exists() helper.