HDDS-15562. EventNotification: persistence strategy for consumer checkpoint (via distributed RocksDB update)

[gardenia]

Please describe your PR in detail:

Persist the checkpoint within the OM RocksDB metadata table using a distributed Ratis update message so that another OM can pick up if the leader changes.

Technical Solution:

• Update the RocksDB metadata table (OMSetEventNotificationCheckpointRequest) and distribute this to other OMs via Ratis (SetEventNotificationCheckpointRequest)

Checkpoint Throttling:

• We update our local progress in-memory on every transaction batch, but throttle the persistent Ratis writes (configurable via OZONE_OM_PLUGIN_CHECKPOINT_SAVE_INTERVAL, defaulting to every 100 transactions).
• The intent is to prevent saturating the Ratis log or causing write storms on RocksDB while maintain our at-least-once delivery guarantee.
• If a Ratis write fails, throttling is bypassed to ensure the next update cycle retries immediately.

Error Handling:

• Both loading and saving failures are non-blocking for background polling progress
• On load failures, we log a warning and fallback to starting from transaction 0/null.
• On save failures, we log a warning but always advance progress in-memory to ensure progress but conform to at-least-once event delivery.

What is the link to the Apache JIRA

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

How was this patch tested?

Unit tests

[gardenia]

NOTE: this is a rework of the original implementation which used Ozone filesystem bucket property metadata to store the properties (PR and review comments from @ChenSammi can be found here #10515).

This approach of using a distributed write to the RocksDB metadata table for persisting the checkpoint was suggested by @ChenSammi in review comments you can find on the above PR.