HDDS-14735. ComponentVersions should not be compared using int values.

[errose28]

What changes were proposed in this pull request?

The int representation of component version should only be used for serialization and should not be checked directly by callers. Direct checking is error prone for various reasons, including FUTURE_VERSION serializing to -1 and mixing up comparison operators like < vs <=. It is also bad for readability. This PR provides utilities to make the serialized value opaque and provides a more robust comparison utility method.

ComponentVersion implementations now contain the following methods:

• serialize (from HDDS-14723. Create one common interface for LayoutFeature and ComponentVersion #9832): Should only be called when sending a version over the network or to disk
• deserialize: Should only be called when reading a version from the network or disk
• isSupportedBy: Should be used to check version compatibility between client and server. This also wraps the deserialization.
  • This will also be wrapped by VersionManager#isAllowed to check against apparent version in
    HDDS-14732
• For example for the client to check "Does this datanode support read block streaming?" you would write

int dnVersion = dnDetails.getCurrentVersion(); // Get the datanode's version that was sent over the network.
if (HDDSVersion.STREAM_BLOCK_SUPPORT.isSupportedBy(dnVersion)) { ... }

All existing client/server version checks have been migrated to these new methods.

Additionally, CURRENT_VERSION has been renamed to SOFTWARE_VERSION in HDDSVersion and OzoneManagerVersion to reflect the terminology used in the new versioning system. For now ClientVersion continues to use CURRENT_VERSION to refer to the latest version because clients are stateless and will not have apparent versions. TBD if we standardize this terminology so clients also refer to their latest version as SOFTWARE_VERSION in the future.

Some changes were generated by Cursor under my guidance and review.

What is the link to the Apache JIRA

HDDS-14735

How was this patch tested?

• No functional change is expected. Existing tests pass on my fork (with some unrelated network timeouts)
• Unit tests for the new isSupportedBy and serialize/deserializemethods added to TestComponentVersionInvariants.

[errose28]

There are some cases that are calling serialize just because they were using ints previously, although it looks like they should be migrated to passing in ComponentVersion and leaving the serialization for a lower level. These include methods in:

• Pipeline
• DatanodeDetails
• DatanodeUsageInfoProto
• OmKeyInfo
• StorageContainerLocationProtocolClientSideTranslatorPB
• Placements into auditMap

Given the size of this change it would probably be better to address these cases in a follow-up. I filed HDDS-14753 for this task, although it is not a blocker to proceeding with implementing the new version managers.

[sodonnel]

LGTM - I just had one question about why the latest entry is the array length minus 2, rather than 1.

[errose28]

@sodonnel I added a comment explaining the behavior, and filed HDDS-14753 to address this comment. PR should be ready for another review.

[sodonnel]

LGTM - thanks for adding that comment. CI is green now, so go ahead and commit.

[errose28]

Thanks @sodonnel for the review. Turns out the upgrade acceptance failure was just another network issue:

Error response from daemon: Head "https://ghcr.io/v2/apache/ozone-runner/manifests/20260206-2-jdk21": Get "https://ghcr.io/token?scope=repository%3Aapache%2Fozone-runner%3Apull&service=ghcr.io": context deadline exceeded (Client.Timeout exceeded while awaiting headers)