Count distinct entities in TestAdvancedSearch data-API helpers

[dmaffitt]

This change hardens TestAdvancedSearch so it can take into account pre-existing data. This surfaced while running tests on the tomcat10-compatible XNAT.

Problem

TestAdvancedSearch.testSubjectSearch and testSubjectJoinSearch fail with count mismatches (e.g. expected:<66> but was:<64>) whenever any subject visible to the test user is shared into another project — including the shared subjects this test itself creates in addTestProjects().

Root cause: the count assertions compare the stored-search result size against get*CountFromDataApi(), which returned the raw row count of the /subjects and /experiments data-API listings. Those listings fan out one row per accessible project membership, so a shared subject/session is counted multiple times, while the stored searches return DISTINCT entities. The two cardinalities are therefore only equal on a pristine, share-free server. This is a test-side cardinality mismatch, not a server regression.

Relationship to the earlier hardening commit

This is the same fragility the earlier commit 8877213 "Make TestAdvancedSearch more resilient to pre-existing data" set out to fix — and it got the label assertions right by switching exact-equality to assertContainsAll(...) subset checks (those still pass). But for the counts it replaced assertEquals(subjectLabels.size(), results.size()) (own-object count) with assertEquals(getSubjectCountFromDataApi(), results.size()) (data-API row count). That made the counts robust to pre-existing data (both endpoints see it) but newly fragile to sharing fan-out, because /data/subjects fans out per membership while the search is DISTINCT. In other words, 8877213 hardened the subset checks but left the count checks comparing two endpoints with different cardinality semantics. This PR completes that work.

Fix

Rework all four get*CountFromDataApi() helpers to count distinct identities via shared dataApiRows() / distinctRowCount() helpers:

• subject / session / qc → key on ID
• scan → key on (xnat:mrsessiondata/id, scan/id)

This keeps the "compare against current global server state" intent of 8877213 while making the counts comparable to the DISTINCT searches regardless of sharing or leftover data.

Verification

Ran -Dtest=TestAdvancedSearch against a live server: testSubjectSearch and testSubjectJoinSearch now pass (class failures 3 → 1). Compiles under JDK 8.