Deprecate HELIX_DISABLED_REASON and refactor how InstanceOperation is represented in instance configs.

Issues

[x] Deprecate HELIX_DISABLED_REASON and HELIX_DISABLED_TYPE as we will no longer be using the HELIX_ENABLED field and this reason field is too specific to HELIX_ENABLED.

[x] Refactor InstanceOperation into listField which will look like:

"HELIX_INSTANCE_OPERATIONS" : ["{\"OPERATION\":\"ENABLE\",\"SOURCE\":\"AUTOMATION\",\"TIMESTAMP\":\"1716510701306\",\"REASON\":\"Cloud event in DefaultCloudEventCallback at 1716510701283\"}","{\"OPERATION\":\"ENABLE\",\"SOURCE\":\"DEFAULT\",\"TIMESTAMP\":\"1716510659104\",\"REASON\":\"\"}"]

Description

Deprecate HELIX_DISABLED_REASON and HELIX_DISABLED_TYPE and refactor INSTANCE_OPERATION to be HELIX_INSTANCE_OPERATIONS listField.

In order to prevent conflicts from different clients setting the InstanceOperation. We will now introduce the HELIX_INSTANCE_OPERATIONS.

The list will be ordered by the earliest to the most recent operations. As before, any client using the old helix enabled APIs will always take precedence over the INSTANCE_DISABLED_OVERRIDABLE_OPERATIONS when those fields are set.

When users of the new InstanceOperation APIs set the operation type to be DISABLE, we will also set the old HELIX_ENABLED field for backwards compatibility.

For all invocations of InstanceOperation APIs, the source will be USER unless otherwise specified. In most cases, this is the trigger used. If an AUTOMATION source is used a separate entry will made in the list. Whichever non ENABLE InstanceOperation entry was created last is the active InstanceOperation that is used in the controller and the returned from getInstanceOperation API.

Tests

[x] Added TestInstanceConfig#testInstanceOperationReason
[x] Added TestInstanceConfig#testInstanceOperationMultipleSources
[x] Added TestZkHelixAdmin#testSetInstanceOperation
[x] Fix lots of tests to use new APIs

Changes that Break Backward Compatibility (Optional)

This change is backwards compatible with HELIX_DISABLED_REASON and HELIX_DISABLED_TYPE.
This is backwards incompatible with InstanceOperation simpleField being removed, but that has not been released in open source yet, so it is only a consideration for internal release.

Commits

My commits all reference appropriate Apache Helix GitHub issues in their subject lines. In addition, my commits follow the guidelines from "How to write a good git commit message":
1. Subject is separated from body by a blank line
2. Subject is limited to 50 characters (not including Jira issue reference)
3. Subject does not end with a period
4. Subject uses the imperative mood ("add", not "adding")
5. Body wraps at 72 characters
6. Body explains "what" and "why", not "how"

Code Quality

My diff has been formatted using helix-style.xml (helix-style-intellij.xml if IntelliJ IDE is used)

This PR is ready to be merged!

Final Commit Message

Deprecate HELIX_DISABLED_REASON and HELIX_DISABLED_TYPE; Refactor INSTANCE_OPERATION to HELIX_INSTANCE_OPERATIONS List Field

To prevent conflicts from different clients setting the InstanceOperation, we are introducing the HELIX_INSTANCE_OPERATIONS list.

Key changes:
- Clients using the old Helix enabled APIs will take precedence over INSTANCE_DISABLED_OVERRIDABLE_OPERATIONS when those fields are set.
- When the new InstanceOperation APIs set the operation type to DISABLE, the old HELIX_ENABLED field will also be set for backwards compatibility.
- For all InstanceOperation API invocations, the source will default to USER unless specified otherwise. An AUTOMATION source will create a separate entry in the list.
- The most recent non-ENABLE InstanceOperation entry will be the active InstanceOperation used by the controller and returned by the getInstanceOperation API.

These changes ensure smoother operation transitions and maintain compatibility with existing APIs.

apache / helix