HDDS-13823. Initial s3v volume cache entry will not be evicted until OM restart

[0lai0]

What changes were proposed in this pull request?

Change the epoch of the initial creation of an s3v volumeTable cache entry from the current maximum transaction ID to DEFAULT_OM_UPDATE_ID (-1). This ensures that its cache entry will subsequently be cleared by the normal eviction process.

Please describe your PR in detail:

This is a minor caching issue in OzoneManager related to the S3G volume (s3v).

1. Inconsistent State: When the very first S3G volume is created in OzoneManager#addS3GVolumeToDB, its updateID is correctly set to -1 (the default). However, its cache epoch is incorrectly set to the max transaction ID.
2. Consequence: Because this cache entry has the highest possible epoch, the cache eviction mechanism assumes it's the newest item and will never evict it.
3. Impact: This is considered a minor issue. It only affects that single cache entry for the initial volume, and the problem disappears after the OzoneManager (OM) is restarted, as the cache is rebuilt.

What is the link to the Apache JIRA

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

[swamirishi]

LGTM thanks for the patch @0lai0 . BTW this patch is inconsequential since volumeTzbl willl have a full cache

[ivandika3]

@0lai0 Thanks for the patch. LGTM +1.

As mentioned in https://issues.apache.org/jira/browse/HDDS-13823, you can attempt to write the reproduction test. However, if it's too difficult, I'm OK with merging this.

[jojochuang]

Merged. Thanks @swamirishi @0lai0

[0lai0]

Thank you all for your responses.
： ）