HDDS-16338. Fix no-op table size assertions in TestHSync

[shuan1026]

What changes were proposed in this pull request?

TestHSync had four no-op AssertJ calls of the form assertThat(n == collection.size()). assertThat(boolean) only builds an AbstractBooleanAssert, so those size checks never failed.

They live in two tests:

• testHSyncOpenKeyCommitAfterExpiry: after expire, OpenKeyCleanupService should commit the hsynced open key and delete the non-hsync one. The size checks are about this test's key1/key2, not the whole tables.
• testHSyncOpenKeyDeletionWhileDeleteDirectory: after hsync, openFileTable should have that one open key before the directory is deleted.

This class shares one static bucket and getOpenKeyInfo / getKeyInfo scan the entire layout. Turning the first test's checks into global assertEquals failed CI (expected: <1> but was: <4> on fileTable; round 1) because other tests leave committed keys behind. That is shared test state, not an hsync/cleanup product bug.

This PR:

• replaces all four no-ops with assertEquals, matching the rest of the file
• scopes the three expiry-test counts with filterByKeyName(..., key1, key2)

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-16338

How was this patch tested?

• Round 1 (global table assertEquals only): failed TestHSync.testHSyncOpenKeyCommitAfterExpiry: https://github.com/shuan1026/ozone/actions/runs/33292933066/job/99208880146
• Round 2 (with filterByKeyName): full fork CI: https://github.com/shuan1026/ozone/actions/runs/33299986156

[chihsuan]

Thanks for the patch! @shuan1026 +1 LGTM

[chihsuan]

Just a thought, would getFileName() work better here than getKeyName()?

[sravani-revuri]

Thanks for the patch @shuan1026 ! just a quick questions and nit below.

[sravani-revuri]

Minor question:
As i see in testHSyncOpenKeyCommitAfterExpiry now the keys are checked to avoid failure from other tests having entries in the respective tables. Curious why this test also isn't doing the same or is it safe to assume the open table is empty from earlier tests?

[shuan1026]

Minor question: As i see in testHSyncOpenKeyCommitAfterExpiry now the keys are checked to avoid failure from other tests having entries in the respective tables. Curious why this test also isn't doing the same or is it safe to assume the open table is empty from earlier tests?

Thanks for the review @sravani-revuri! Yes, it isn't safe to assume that.

Scoped this test the same way: the size check, the DELETED_HSYNC_KEY wait and the final wait now all filter to this test's key. Also filtered the one remaining whole-table wait in testHSyncOpenKeyCommitAfterExpiry.

[sravani-revuri]

nit: Unrelated to change, but should this be renamed to fileTable since it reads Keytable not open one?