fix(jetty): make init.d stop actually stop and start after DB (#6)

[natechadwick-intsof]

Summary

Fixes the two Linux 8.1.7 SysV / init.d field failures from #6:

1. service <name> stop / /etc/init.d/<name> stop did not actually stop
   the Jetty JVM.
2. On reboot, the init.d service started before MySQL/MariaDB was
   reachable.

Problem 1 — stop did not stop

Two bugs in system/Tools/jetty/defaults/bin/rxjetty.sh:

• The start-stop-daemon guard checked $UID -eq 2 (the daemon
  account), so the start-stop-daemon branch was effectively dead code.
  Stop always fell through to a PID-file-only kill path.
• The start-stop-daemon -K signal was SIGHUP, which Java does not
  treat as a stop signal. Even when the branch did fire it signalled the
  wrong intent.

The stop path now:

• Resolves the actual Java/Jetty PID via a new find_jetty_pid helper
  that tolerates stale, missing, or wrong PID files by scanning
  /proc/*/cmdline for a Java process whose -Djetty.base matches
  JETTY_BASE (the same recovery pattern that StopJetty.sh already
  used).
• Signals SIGTERM (the default for start-stop-daemon -K) and
  escalates to SIGKILL after STOP_TIMEOUT (default 60s).
• Re-verifies the JVM is actually gone before exiting 0. A second
  service <name> stop on an already-stopped service is now
  idempotent rather than failing.

Problem 2 — starts before DB on reboot

• The shipped LSB header only declared $local_fs $network and the
  chkconfig priority was 20 80 (start very early). The header now
  declares Required-Start: $local_fs $network $remote_fs and
  Should-Start: $named mysqld mysql mariadb, and the chkconfig line
  is raised to 2345 99 01 so the CMS starts as one of the last
  services on boot.
• install-jetty-service.sh now registers update-rc.d with explicit
  start 99 2 3 4 5 . stop 01 0 1 6 . (and K01 on the Solaris
  fallback) so SysV systems without chkconfig get the same ordering.
• For installs with a remote DB (e.g. AWS RDS) where there is no local
  mysqld init script to order against, rxjetty.sh now exposes
  WAIT_FOR_DB_HOST / WAIT_FOR_DB_PORT / WAIT_FOR_DB_TIMEOUT /
  WAIT_FOR_DB_INTERVAL. When WAIT_FOR_DB_HOST is set, the start
  path probes host:port with nc -z (bash /dev/tcp fallback) until
  the timeout elapses before launching Jetty. install-jetty-service.sh
  ships these vars (empty by default) in the /etc/default/<service>
  template and prints a post-install hint about configuring them.

Acceptance from #6

• service <name> stop and /etc/init.d/<name> stop leave no
  CMS/Jetty JVM.
• service <name> start after stop starts cleanly.
• service <name> restart works end-to-end.
• Stale/missing PID file: recovered via /proc scan; never exits 0
  while Jetty still runs.
• Cold reboot with local MySQL/MariaDB: CMS reaches running without
  manual start (via LSB Should-Start + chkconfig 99 01).
• Remote DB: opt-in wait loop via WAIT_FOR_DB_HOST for first boot
  after reboot.
• Installer lists how to set DB wait host/port for non-local DB
  (post-install hint).
• No hard dependency that breaks installs with remote-only DB and
  no local mysqld init script.

Verification

• bash -n clean on all three modified files.
• Shellcheck on the new helpers and the modified start/stop blocks
  produces zero new warnings (the only warnings the linter raises are
  pre-existing issues in unrelated lines).
• Helper smoke test, 14/14 pass:
  • find_jetty_pid returns the live PID when the PID file is correct,
    recovers from a stale PID via the /proc scan, removes the stale
    PID file, and returns failure cleanly when nothing matches.
  • wait_for_db is a no-op when WAIT_FOR_DB_HOST is unset, succeeds
    on a reachable port, fails on a closed port, and is disabled by
    WAIT_FOR_DB_TIMEOUT=0.
  • stop_pid kills a cooperative process, no-ops on a dead PID, and
    escalates TERM → KILL within ~3s on a SIGTERM-ignoring
    process, confirming the process is dead before returning 0.

Notes

• The same buggy rxjetty.sh blob exists on main (same sha as
  development-8.1.x), so this branch targets main for the merge to
  actually fix the issue. Base is a clean ancestor of main.
• buildNumber in Version.properties is not bumped here, per
  AGENTS.md the post-merge workflow handles that.
• target/ copies of rxjetty.sh are build artifacts; they regenerate
  from system/Tools/jetty/ during the perc-jetty Maven assembly.

Files changed

 CHANGELOG.md                                       |   8 +
 system/Tools/jetty/defaults/bin/rxjetty.sh         | 230 ++++++++++++++++++---
 .../Tools/jetty/service/install-jetty-service.sh   |  22 +-
 3 files changed, 225 insertions(+), 35 deletions(-)

Fixes #6

[natechadwick-intsof]

Closing this PR — its base (the local development-8.1.x snapshot) diverged from the project's actual main line while the rewire of the repo to point at intersoftdatalabs-in/percussioncms-java8 happened. The PR is now CONFLICTING and a rebase onto current main would have to drop the CHANGELOG.md edit (that file does not exist on main) and force-push — destructive enough that I'd rather not.

A new branch is being opened from the current main with the same two-file script fix. The CHANGELOG.md history entry is dropped because the file does not exist on main.