PHOENIX-7954 Update phoenix-adapters to use latest 5.3.2 phoenix

[lokiore]

What

Bump <phoenix.version> in pom.xml from 5.3.1 → 5.3.2, now that Apache Phoenix 5.3.2 has been released and published to Maven Central.

JIRA: PHOENIX-7954

Changes

• pom.xml (line 46): <phoenix.version>5.3.1</phoenix.version> → <phoenix.version>5.3.2</phoenix.version>

All consumed Phoenix artifacts (phoenix-core, phoenix-core-client, phoenix-core-server, phoenix-hbase-compat-2.5.4) resolve at ${phoenix.version} and are available at 5.3.2 on Maven Central.

Verification

Full mvn clean install locally against Maven Central: all modules (phoenix-ddb-utils, phoenix-ddb-rest, phoenix-ddb-assembly, coverage-report) compile and package cleanly against 5.3.2; the suite runs 1011 tests with 0 errors.

The only failing test is GetRecordsIT.testGetRecordsWithPartitionSplits, which is a pre-existing, flaky, order-sensitive test-harness issue — not a product regression, not a data-integrity issue, and not attributable to this version bump. Evidence:

• Proven flaky (non-deterministic). Re-running the test class 3× on the same 5.3.2 build produced PASS / FAIL / PASS, and the failing record index differed between runs (e.g. record 5911 in one failure, record 4918 in another). Identical build, different outcome ⇒ flake.
• No data loss/duplication. TestUtils.validateRecords asserts record-set size equality first (TestUtils.java:231) and only then compares keys() index-by-index (:244). Failures land on the index compare, so both streams return an equal number of records — one position is merely out of order (both PK pairs are well-formed consecutive values the test itself generated).
• Root cause is an insufficient sort key. Both streams are re-sorted by approximateCreationDateTime alone, with no tiebreaker (GetRecordsIT.java:427, :438). That timestamp is coarse (whole-second granularity), so many records tie; a deterministic total-order key (sequenceNumber) exists on every record but the sort ignores it. Tied records legitimately order differently between the single-shard DynamoDB scan and the multi-shard Phoenix concatenation under partition splits.
• Not attributable to 5.3.1 → 5.3.2. The only substantive read-path change in 5.3.2 is PHOENIX-7878 (CDCVersionFilter), which returns only INCLUDE/SKIP/NEXT_COL and is per-row scoped — an HBase filter cannot reorder the scan stream, and any defect there would surface at oldImage()/newImage(), not keys().

The permanent fix belongs in the test, not this PR: add a sequenceNumber tiebreaker to both sorts (.thenComparing(...) at GetRecordsIT.java:427 and :438) so the comparison is order-deterministic. Tracked separately from this version bump.

[virajjasani]

+1