feat(mysql-dual-conn, tidb-stmt-cache): exercise COM_STMT_RESET + prepared-stmt orphan-EXECUTE

[khareyash05]

Description

This PR bundles two related sample-app additions whose CI counterparts both land on keploy/keploy@fix/mysql-synthetic-prepare-ok-cachePrepStmts.

mysql-dual-conn/ — /api/oms/stmt-reset/{n} (existing in this PR)

Adds GET /api/oms/stmt-reset/{n} that re-executes a server-side prepared statement n times on the same JDBC connection. Also updates the OMS JDBC URL with useServerPrepStmts=true&cachePrepStmts=true&useCursorFetch=true so MySQL Connector/J 8.x emits COM_STMT_RESET between re-executions.

Exercises keploy's COM_STMT_RESET synthetic-OK fallback (keploy/keploy#4217).

tidb-stmt-cache/ — new sample (this commit)

New Spring Boot 3 + JdbcTemplate sample targeting pingcap/tidb:v8.5.6 on :4000. Drives MySQL Connector/J prepared-statement traffic with useServerPrepStmts=true&cachePrepStmts=true. HikariCP pool LIFO causes Connector/J to skip COM_STMT_PREPARE and emit COM_STMT_EXECUTE only on cache-hit calls — exercising the orphan-EXECUTE matching path that keploy's param-alone fallback (match.go:967-976, from commit b2e68adb) handles.

Endpoints:

• GET /api/health — plain SELECT 1, used by wait_for_app.
• GET /api/kv/{v} — prepared SELECT ? AS v; same SQL across calls so the cache hits.
• GET /api/kv/insert-select/{v} — prepared INSERT + prepared SELECT on the same connection, two concurrent prepares.

TiDB runs with --store=unistore so boot is ~5s and there's no PD/TiKV flakiness. Schema is bootstrapped by a CommandLineRunner inside the app — no init.sql needed (TiDB unistore doesn't run /docker-entrypoint-initdb.d/).

Type of change

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

mysql-dual-conn was previously tested as described in the original PR body.

tidb-stmt-cache is exercised end-to-end via the keploy-side companion PR's CI matrix entry — local reproduction against TiDB wasn't run because the keploy proxy needs eBPF / Linux, which isn't available on the dev host. Each of the three compat-matrix cells (record_latest_replay_build, record_build_replay_latest, record_build_replay_build) will record + replay traffic that includes cachePrepStmts-cached EXECUTEs. The keploy-side script also strips one COM_STMT_PREPARE mock from the recorded mocks.yaml before replay as a deterministic guard so the param-alone fallback fires on every run regardless of natural HikariCP timing.

# Local sanity check (TiDB only, no keploy proxy)
cd tidb-stmt-cache
docker compose up -d
mvn -B -DskipTests package
java -jar target/tidb-stmt-cache-0.0.1-SNAPSHOT.jar &
curl http://localhost:8080/api/health
curl http://localhost:8080/api/kv/1
curl http://localhost:8080/api/kv/2
curl http://localhost:8080/api/kv/insert-select/42

Additional Context

• The mysql-dual-conn/ endpoint deliberately keeps the existing dual-handshake test path unaffected — Camunda pool's JDBC URL is unchanged.
• tidb-stmt-cache/ is a new top-level directory next to mysql-dual-conn/; the two samples share no code.

Related: keploy/keploy#4217 (COM_STMT_RESET fix), keploy/keploy b2e68adb (orphan-EXECUTE fix).

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• I have signed the commit message (`--signoff`)