Add typed feature flag getters

[cathleeny]

Description

• Add typed getters for the six SAFE feature flag value types using the existing JDBC cache.
• Return an empty result for missing, malformed, or incorrectly typed values.

Testing

• mvn -pl jdbc-core -Dtest=DatabricksDriverFeatureFlagsContextTest test

Telemetry Errors

• Not applicable — this PR does not add or change a telemetry-visible error.
• Applicable — the error uses DatabricksDriverErrorCode where appropriate, and any
  new code is uniquely numbered and tested.
• Applicable — its driver/server/user classification is linked, or maintainer help is
  requested because the author cannot access the classification.

Additional Notes to the Reviewer

This reuses the existing feature flag cache and fetch lifecycle; no connection or session behavior changes.

[peco-review-bot]

Verdict: 1 Nit

Looks good — clean, well-tested refactor that renames isFeatureEnabled→getBoolean (all callers updated, grep confirms no stragglers) and adds six JSON-backed typed getters with correct empty-on-missing/malformed/mistyped semantics. Only nits: the redundant list copy in getStringList (inline), and getBoolean(null) throws NPE rather than returning false despite the Javadoc framing null-ish values as "missing" — this is explicitly asserted in the test and all production callers pass constant names, so it's acceptable as-is.

Other findings

• ⚪ Nit — getStringList builds a fresh ArrayList (result) and then wraps it with List.copyOf(result), which allocates a second backing array. Since result is already a private, freshly-created list, you can return it directly (or Collections.unmodifiableList(result)) to avoid the extra copy. Minor — not a correctness issue.

[peco-review-bot]

Verdict: 1 Low

Looks good — clean, well-tested addition of typed feature-flag getters with correct JSON type/range validation and empty-on-malformed semantics; changelog entry present and the isFeatureEnabled→getBoolean rename is applied consistently across callers and tests. One low-severity note about inconsistent null-handling between getBoolean (throws NPE) and the new typed getters (return empty).

[peco-review-bot]

🔵 Low — Null-handling is inconsistent across the getter family. getBoolean(null) throws NullPointerException (Guava Cache.getIfPresent(null) rejects null keys — and the test asserts this), while every typed getter (getInt32/getInt64/getDouble/getString/getStringList) routes through parse(), which guards name == null and returns an empty result instead. A caller treating these six methods as a uniform API will get a thrown exception from one and a graceful empty from the others for the same null input. This matches the pre-existing isFeatureEnabled behavior so it's not a regression, but since the typed getters are new and establish the "missing/invalid → empty" contract, consider making getBoolean consistent (e.g. guard null the same way) or documenting the divergence in the Javadoc, which currently only mentions "missing values default to false" and says nothing about null throwing.

(Anchored to the nearest changed line — see the description for the exact location.)

[jay-xiao446]

What's the motivation of adding types? Does it unblock any feature?

[cathleeny]

What's the motivation of adding types? Does it unblock any feature?

There's no OSS JDBC feature blocked by this. This is to unify cache behavior across all drivers and support different flag types for the future (e.g. ADBC currently uses other types besides bools)