HDDS-16363. Fix split-schema MPU size tracking in Recon event handlers

[priyeshkaratha]

What changes were proposed in this pull request?

Problem:
The Recon API endpoint /api/v1/keys/open/mpu/summary was returning zero sizes for split-schema multipart uploads (MPUs) because event handlers were not tracking part sizes from the multipartPartsTable. Only legacy-schema MPU sizes
(embedded in multipartInfoTable values) were tracked by events. Split-schema MPU sizes were only calculated during periodic reprocess, causing newly created split-schema MPUs to show zero sizes until the next reprocess run.

Root Cause:
When split-schema MPU support was added (HDDS-14666), the MultipartInfoInsightHandler event methods were updated to use forEachLegacyPart(), which returned early for split-schema MPUs without processing any sizes. Event handlers had no mechanism to access multipartPartsTable to fetch split-schema part sizes incrementally.

Solution:

1. Extended OmTableHandler interface to pass OMMetadataManager to event handlers, enabling access to multipartPartsTable during event processing.

2. Added new applySplitSchemaPartSizes() method to MultipartInfoInsightHandler that:

   • Queries multipartPartsTable for all parts of a split-schema MPU
   • Calculates unreplicated and replicated sizes for each part
   • Updates size maps on PUT/DELETE/UPDATE events immediately

3. Integrated split-schema size tracking into PUT, DELETE, and UPDATE event handlers.

4. Updated DeletedKeysInsightHandler and OpenKeysInsightHandler to accept the new OMMetadataManager parameter (no-op for these handlers).

What is the link to the Apache JIRA

HDDS-16363

How was this patch tested?

• Added new test testProcessForSplitSchemaMPU() to verify split-schema MPU sizes are calculated immediately on PUT/DELETE events without waiting for reprocess.
• Test creates split-schema MPU with 3 parts of 100 bytes each, verifies:
  • PUT event results in correct sizes: 300 bytes unreplicated, 900 bytes replicated
  • DELETE event resets sizes to 0
• All 14 existing tests continue to pass.

Tested manually

[devmadhuu]

Thanks @priyeshkaratha for the patch. Kindly see some comments.

[devmadhuu]

I don't think this actually fixes split-schema sizes via events, and in some cases it makes the numbers worse than before.

The problem is that applySplitSchemaPartSizes reads the live multipartPartsTable, but Recon commits the WAL batch to its own RocksDB before process() runs. So by the time these handlers execute:

On UPDATE (every part commit): we call applySplitSchemaPartSizes once to subtract the old value and once to add the new value, but both calls scan the same live parts table for the same uploadId with the same replication config. They cancel to exactly zero, so part commits never accumulate any size.
On DELETE (complete/abort): the part rows are deleted in the same batch as the multipartInfoTable row, so the scan finds nothing and subtracts 0.
On PUT (initiate): normally there are no parts yet, so it adds 0 — but if initiate + commits land in the same Recon sync, PUT sees the already-committed parts and adds the full size. Since DELETE later subtracts 0, that size stays in the counter forever until the next reprocess.

[devmadhuu]

This adds a lot of work to the event path for no benefit. In split schema, every part commit rewrites the multipartInfoTable row, which Recon sees as an UPDATE. Each UPDATE now opens two RocksDB iterators over multipartPartsTable and scans all parts committed so far for that upload (once for the subtract pass, once for the add pass), deserializing each OmMultipartPartInfo.

Since parts arrive incrementally, commit #k scans ~2k rows, so a single MPU with N parts does about N² part-row reads over its lifetime. S3 allows up to 10,000 parts, so one big upload is on the order of 100M reads — and this runs on the same thread that keeps Recon in sync with OM, so it directly increases Recon lag. Concurrent uploads multiply it.

And as noted in the correctness comment, the two passes cancel to zero, so this is effectively pure overhead. Moving accounting to multipartPartsTable events would make it O(1) per part instead of O(parts²) per MPU.