[coverage] Conformance findings: CONNPOOL-003 #1677

Summary

Surfaced by the multi-language coverage fan-out while conformance-testing these SPEC-IDs against databricks/databricks-jdbc. Each finding is committed as an expected-failure (xfail) test in the coverage PR — the test asserts the CORRECT (post-fix) behavior and stays red until THIS driver (databricks/databricks-jdbc) is fixed, then flips green as a tripwire.

Findings

• CONNPOOL-003 [thrift]: Thrift query transport ignores HttpConnectionPoolSize: DatabricksHttpClient.initializeConnectionManager() hardcodes setMaxTotal(1000) instead of connectionContext.getHttpConnectionPoolSize(), though the per-route cap on the adjacent line does read the context and ClientConfigurator (SEA/SDK path) applies the option correctly
  • failing test: testHttpConnectionPoolSizeConfiguration (see the coverage PR diff under tests/)

Reproduce & Expected

CONNPOOL-003 — Verify the driver's HTTP connection-pool sizing option (JDBC HTTP_CONNECTION_POOL_SIZE; Python _pool_maxsize) is honored for the transport that actually carries query traffic -- on EVERY backend th…

Expected (per the shared spec):

• {'label': 'positive_value', 'max_total': 137}
• {'label': 'positive_value'}
• {'label': 'positive_value', 'column': 'value', 'expected': 1}
• {'label': 'zero_value'}
• {'label': 'zero_value'}
• {'label': 'zero_value', 'column': 'value', 'expected': 1}

Context

• The behavior was first fixed in a DIFFERENT driver — reference PR: feat(kernel): forward _pool_maxsize databricks-sql-python#940 — which seeded the shared language-neutral spec. This issue tracks the same conformance gap in databricks/databricks-jdbc; the reference PR is for cross-referencing the intended behavior, NOT a change to this repo.
• Coverage PR carrying the reproducing xfail test(s): https://github.com/databricks/databricks-driver-test/pull/1557