[d-wang-commit]

Description

Verify observable recovery through production interfaces

IoTDBNodeStatusFailoverIT could fail before its status assertions because its JVM Attach control channel timed out. Its JDBC observations also introduced a separate dependency: creating or reconnecting a session during a DataNode failure can require storage that is unavailable. Reusing a connection does not rule out driver reconnection.

Replace the instrumentation with existing ConfigNode RPCs, the existing DataNode status RPC, and actual process stop/restart operations. Remove NodeStatusTestAgent. No production API or Ratis implementation changes are required. Fault-window observations use showCluster, showConfigNodes, and showDataNodes directly; the framework's initial JDBC readiness check still runs while the cluster is healthy.

Reduce the existing nine scenarios to five, each with its own cluster:

• A reported ConfigNode shutdown becomes Stopped, restart clears it, and a later unreported failure becomes Unknown.
• A reported DataNode shutdown remains Stopped across ConfigNode leader failure while the DataNode stays offline.
• ReadOnly and its Manual reason remain visible after leader failure, then clear through shutdown and restart. Live heartbeats may rebuild this state, so this is not an isolated persistence assertion.
• Stopped survives restarting all ConfigNodes; after the DataNode returns and fails without another report, Unknown survives another ConfigNode restart.
• Normal DataNode removal completes and the removed registration does not reappear after leader failure. This scenario uses two healthy DataNodes with Schema/Data Ratis and RF1, as SimpleConsensus does not support removal.

Wait for successful production responses and the expected status instead of forcing repeated leader transfers. Read polling does not replay mutations or rerun whole failed methods. Confirm process exit before restart and stop all test processes before directory cleanup.

Tests

• UT: no tests added or modified; no unit tests run.
• IT: rewrote the existing IoTDBNodeStatusFailoverIT and reduced its scenarios from nine to five; no additional test cases.
• Final local ClusterIT run: 5 tests, 0 failures, 0 errors, 0 skipped, 124.100 seconds on Windows 11 / JDK 17, one fork, CN/DN maximum heap 1024 MB each.
• Recompiled current test sources in the reactor and ran the named Failsafe integration-test/verify executions. Unchanged production classes and node templates were reused. Spotless and git diff --check passed.
• Linux concurrent CI and the downstream edition have not been run for this revision.

Side effects and risks

This changes test code only and deliberately narrows coverage. It does not verify SQL routing through a DataNode, login availability during faults, a live partitioned old leader, no-quorum behavior, individual replicas' internal records, exact snapshot/log boundaries, actual JVM shutdown-hook execution, or a fixed Removing intermediate state. The removal scenario checks registration recovery, not data migration correctness. These guarantees must not be inferred from the five passing scenarios.

The change removes Attach and fault-window authentication dependencies; it does not fix the cause of the CI host/JVM pauses or a Ratis product defect. No claim of equivalent Linux concurrent-load validation is made.

---

This PR has:

• been self-reviewed.
• added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
• been tested in a test IoTDB cluster.

---

Key changed/added classes (or packages if there are too many classes) in this PR

• IoTDBNodeStatusFailoverIT: verify observable status recovery and registration through production RPCs and process failures, with isolated clusters and explicit cleanup.
• NodeStatusTestAgent: removed with the JVM instrumentation control channel.