ci(java/mysql-dual-conn): exercise COM_STMT_RESET in record traffic

[khareyash05]

Describe the changes that are made

• Adds one curl http://localhost:8080/api/oms/stmt-reset/5 inside the existing mysql-dual-conn record loop so the java_linux pipeline exercises the COM_STMT_RESET synthetic-OK fallback introduced in fix(mysql/replay): synthesize OK for unmocked COM_STMT_RESET #4217.
• No other workflow change: the matrix entry, the JAR build, the dual-handshake assertions, and the replay/report check are all unchanged. The new traffic just lands inside send_request alongside the existing /api/query-both, /api/oms, /api/camunda calls.
• The sample-app endpoint itself (and the useServerPrepStmts=true&cachePrepStmts=true&useCursorFetch=true JDBC flags that make Connector/J 8.x emit COM_STMT_RESET) lives in feat(mysql-dual-conn): add endpoint to trigger COM_STMT_RESET samples-java#137 and must merge first.

Links & References

Closes: NA

🔗 Related PRs

• fix(mysql/replay): synthesize OK for unmocked COM_STMT_RESET #4217 — the match.go fix this script now exercises end-to-end.
• feat(mysql-dual-conn): add endpoint to trigger COM_STMT_RESET samples-java#137 — adds GET /api/oms/stmt-reset/{n} to the sample app (must merge before this PR's CI will pass).

🐞 Related Issues

• NA

📄 Related Documents

• NA

What type of PR is this? (check all applicable)

• 📦 Chore
• 🍕 Feature
• 🐞 Bug Fix
• 📝 Documentation Update
• 🎨 Style
• 🧑‍💻 Code Refactor
• 🔥 Performance Improvements
• ✅ Test
• 🔁 CI
• ⏩ Revert

Added e2e test pipeline?

• 👍 yes

This PR is the e2e wiring. The three existing compat-matrix cells (record_latest_replay_build, record_build_replay_latest, record_build_replay_build) will all now record + replay traffic that includes COM_STMT_RESET packets. A regression in the synthetic-OK fallback would surface as either a replay-time Connection closing due to no matching mock found error or a failed test report.

Added comments for hard-to-understand areas?

• 👍 yes — the inline comment in send_request() points at fix(mysql/replay): synthesize OK for unmocked COM_STMT_RESET #4217 and explains why useServerPrepStmts + useCursorFetch are required for Connector/J 8.x to emit COM_STMT_RESET.

Added to documentation?

• 🙅 no documentation needed

Are there any sample code or steps to test the changes?

• 👍 yes, mentioned below

# After keploy/samples-java#137 merges:
RECORD_BIN=/abs/path/to/keploy/out/build/keploy \
REPLAY_BIN=/abs/path/to/keploy/out/build/keploy \
GITHUB_WORKSPACE=/abs/path/to/keploy \
bash -x \$GITHUB_WORKSPACE/.github/workflows/test_workflow_scripts/java/mysql_dual_conn/java-linux.sh

Expected: record log shows the new === /api/oms/stmt-reset/5 === section; replay produces test reports with status: PASSED for every test-set; no Connection closing due to no matching mock found lines in test_logs.txt.

Self Review done?

• ✅ yes

Any relevant screenshots, recordings or logs?

• NA

Additional checklist:

• Have you read the Contributing Guidelines on issues?
• Have you followed the PR Semantics guide for naming this PR?
• Have you followed the Branch Semantics guide for naming your branch?

[github-actions]

🚀 Keploy Performance Test Results

Multi-Run Validation: Tests run 3 times, pipeline fails only if 2+ runs show regression.

Run	P50	P90	P99	RPS	Error Rate	Status
1	2.67ms	3.31ms	4.97ms	100.02	0.00%	✅ PASS
2	2.59ms	3.18ms	4.83ms	100.02	0.00%	✅ PASS
3	2.64ms	3.43ms	4.94ms	100.02	0.00%	✅ PASS

Thresholds: P50 < 5ms, P90 < 15ms, P99 < 70ms, RPS >= 100 (±1% tolerance), Error Rate < 1%

✅ Result: PASSED - Only 0 out of 3 runs failed (threshold: 2)

P50, P90, and P99 percentiles naturally filter out outliers