[7/7] Enable insert batching by default

[sreekanth-db]

🥞 Stacked PR

Use this link to review incremental changes.

• stack/native-batch-legacy-seam [Files changed]
  • stack/native-batch-foundation [Files changed]
    • stack/native-batch-routing [Files changed]
      • stack/native-batch-thrift [Files changed]
        • stack/native-batch-sea [Files changed]
          • stack/native-batch-integration-tests [Files changed]
            • stack/native-batch-activation [Files changed] ← this PR

---

Description

• Enable native server-side batching by default for supported PreparedStatement INSERT batches on DBR 18.2 and later.
• Enable the legacy client-side multi-row rewrite by default for older DBR versions and compatibility fallback.
• Keep EnableNativeBatching=0 and EnableBatchedInserts=0 as independent kill switches.
• Report JDBC batch support when either strategy is enabled.
• Document the 10,000-parameter / 1 MB limits and native BINARY limitation.

Testing

• Focused connection-context, metadata, routing, and prepared-statement unit tests.
• SEA and Thrift fake-service replay tests using real recorded responses.
• Live SEA and Thrift warehouse validation for native and legacy batching branches, limits, transactions, data types, and statement lifecycle.
• Full PR CI across supported JDK and operating-system combinations.

Additional Notes to the Reviewer

• Native batching does not support BINARY values. Binary batches must use legacy client-side batching with EnableNativeBatching=0 and supportManyParameters=1 (EnableBatchedInserts defaults to 1).
• After a successful legacy rewrite chunk, JDBC reports update count 1 for each submitted row because the backend returns a count for the combined multi-row statement rather than separate per-row counts.

[peco-review-bot]

Verdict: 1 Low

Clean activation PR — verified the native/legacy routing so enabling both defaults is safe (native prioritized, legacy fallback, no double execution) and the test updates match the new defaults. One low note on the legacy fallback's hardcoded per-row update counts becoming the default behavior. Reminder (already documented by the author): this is intentionally a draft and must not merge until native BINARY parameter support lands on SEA and Thrift.

Scope: reviewed as a stacked increment (07968b8..head); the parent's changes are reviewed on the parent PR.

[peco-review-bot]

🔵 Low — Flipping EnableBatchedInserts to 1 by default turns on the legacy client-side multi-row rewrite for the DBR < 18.2 fallback path. Note that this path does not read real per-row update counts from the server — executeBatchedInsert hardcodes allUpdateCounts[i] = 1 for every row (see the loop that sets each chunk's counts). So on the new default, callers that inspect executeBatch() return values will always see 1 per row rather than the actual affected-row count, whereas the previous default (batched inserts off) returned the server's real getUpdateCount() per statement. This is the intended design of the batching feature, but it is a user-visible behavior change worth calling out explicitly in the changelog entry (which currently only describes native batching's parameter/size limits, not the update-count semantics of the legacy fallback).