fix(scripts): remove dead sonar-report dep and re-enable container cleanup

[TheAuditorTool]

Summary

Issue #187 reported /usr/bin/jq: Argument list too long when running scripts/runSonarQube.sh. This was caused by the original script accumulating thousands of SonarQube vulnerability results in shell variables and passing them as command-line arguments to jq, which exceeded Linux's ARG_MAX limit (~2MB).

The core fix was already applied in commit 32933c4e6 (Feb 2025) by @darkspirit510, which replaced the shell-based jq result aggregation with a native Java class (SonarReport.java) that paginates the SonarQube API and writes results directly to disk. This PR cleans up leftover artifacts from the intermediate fix that were missed.

Problem Chain (full history)

Date	Commit	State
2022	459108114	Original script: jq accumulates all results in shell variables. Breaks at ~2MB of JSON.
2023	b697dc953	Attempted fix: page size reduced 500 to 20, file-based buffering via buffdump.json/resdump.json. Still unstable per #196.
2025-01	4fb517b57	Replaced jq processing with external sonar-report Go tool. Added sonar-report dependency check.
2025-02	32933c4e6	Replaced sonar-report with native SonarReport.java. But the sonar-report dependency check was left behind.
This PR		Removes the dead sonar-report check and re-enables container cleanup.

Changes

1. Removed dead sonar-report dependency check

The script still had:

if ! command -v "sonar-report" &> /dev/null; then
  echo "sonar-report is required..."
  exit 1
fi

This exit 1 blocked anyone from running the script unless they had sonar-report installed -- a tool that is no longer used since commit 32933c4e6 replaced it with mvn exec:java -Dexec.mainClass="org.owasp.benchmark.report.sonarqube.SonarReport".

2. Re-enabled container cleanup

# Before (leaked container):
#docker stop "$container_name"

# After:
docker stop "$container_name"

The docker stop was commented out in 32933c4e6, leaving a running SonarQube container after every script run.

What jq is still used for (and why it's fine)

The script retains 4 jq calls, all operating on small single-object API responses (not result aggregation):

Line	Purpose	Response size
45	Check SonarQube system status	~50 bytes
60	Extract auth token	~100 bytes
64	Get container IP from docker inspect	~2KB
77	Check Compute Engine task status	~200 bytes

None of these can approach ARG_MAX. The requireCommand jq check is retained because these calls still need it.

Deferred findings (out of scope for #187)

During the audit of SonarReport.java, three issues were identified that are unrelated to the jq overflow but worth tracking separately:

1. No HTTP error checking in apiCall() (SonarReport.java:106-113): HttpURLConnection responses are read from getInputStream() without checking the status code. Non-2xx responses (e.g., 400, 401, 500) will throw an IOException with no useful error context, or in some cases silently return an error body that breaks Jackson deserialization.

2. SonarQube 10K result hard cap (SonarReport.java:84-100): The issues/search API enforces a hard limit of 10,000 results (p * ps <= 10000). At PAGE_SIZE = 500, page 21 would request offset 10,500 and receive an HTTP 400. For Enterprise editions reporting 18K+ vulnerabilities (as noted by @zoobinn in /usr/bin/jq: Argument list too long #187), this would silently truncate results or crash.

3. Off-by-one in page count (SonarReport.java:94): (total / PAGE_SIZE) + 1 uses integer division and unconditionally adds 1. When total is an exact multiple of 500, this fires one extra empty-page request. Harmless but wasteful.

Test plan

• Run scripts/runSonarQube.sh on a machine with Docker but without sonar-report installed -- should no longer exit with "sonar-report is required"
• After script completes, verify no orphaned sonarqube-benchmark container is running (docker ps)
• Verify results/Benchmark_*-sonarqube-v*.json is written with both issues and hotspots arrays