Add Modbus‑TCP reachability probe (PLC check)

[abishekve]

Background

Pulse monitors availability using ICMP, TCP, and HTTP; manufacturing networks also require PLC reachability, making Modbus‑TCP a pragmatic, low‑overhead OT probe aligned with the availability‑only scope.
The new probe should integrate with the existing ProbeService → OutageDetectionService pipeline, reuse timeout semantics, record RTT, and appear consistently in API, CSV, and live board.

Objective

Implement a new probe type modbus that reports UP on successful reachability via Modbus‑TCP with RTT, and DOWN on timeout or transport errors, without deep device interrogation by default.

Scope

• Backend probe: Modbus‑TCP reachability using a fast TCP connect to port 502, with optional “strict” request/response mode to validate a single PDU when configured.
• YAML schema: add type: modbus with host, port (default 502), timeout, retries, and an optional strict flag; validate and surface in Apply/diff/versioning.
• UI/UX: configuration editor support for modbus, live board labeling, endpoint detail display, and CSV/API parity for probe type and RTT fields.

Non‑Goals

• No continuous Modbus polling, register reads, or performance metrics beyond reachability and RTT in this issue.
• No authentication/secure Modbus extensions or device model discovery in this phase.

Design Notes

• Result mapping: Success = UP with RTT measured as TCP connect time or single‑request roundtrip when strict=true; Failure = DOWN with categorized error (timeout/refused/reset/unreachable).
• Timeouts/retries: Adopt existing per‑probe timeout and single‑attempt semantics; wire through existing cancellation pattern and error reporting.
• Outage flow: Feed CheckResult into OutageDetectionService unchanged to honor 2/2 flap damping and transactional outage open/close.
• IPv6/dual‑stack: Respect host resolution and address family selection in line with other probe implementations.

Tasks

• Backend
  • Implement ModbusTcpProbe with connect‑only reachability and optional strict PDU path with clear error categories and RTT capture.
  • Extend ProbeService.ProbeAsync switch to route type: modbus and return standardized CheckResult.
  • Add unit tests for success, timeout, refused, unreachable, and strict‑mode invalid response; add integration test with a mock Modbus server.
• Configuration & Apply
  • Update config.schema.json to include enum value modbus with properties: host, port (default 502), timeout, retries, strict (boolean).
  • Extend ConfigurationParser validations and Apply diff to show additions/changes, preserving version snapshots and warnings on invalid combinations.
• API/UI
  • Ensure API DTOs and CSV export include probe type modbus and RTT; maintain consistent labeling in endpoint detail and lists.
  • Update ConfigurationEditor and related form controls for modbus fields with inline validation and help text.
• Ops & Docs
  • Add docs examples for modbus endpoints, defaults, and strict mode caveats; note firewall and port 502 considerations.
  • Add basic performance note to probes spec about expected connect‑time RTT and error classification for modbus.

Acceptance Criteria

• A YAML endpoint with type: modbus applies cleanly, appears in diff/versioning, and is visible/editable in the UI including defaults.[4]
• Modbus endpoints report UP when reachable within timeout, DOWN on timeout/refused/unreachable, with RTT populated and errors categorized.[1]
• Outage transitions honor 2/2 damping for modbus results and persist open/close events transactionally.
• API and CSV show probe type modbus and RTT; live board and detail pages render the type clearly.

Risks & Mitigations

• Device variance and strict PDU compatibility across PLCs; mitigate by defaulting to connect‑only mode and documenting strict mode as optional.
• Port filtering or DPI on OT networks causing resets; mitigate with clear error categorization and operator guidance.

Testing Plan

• Unit tests for ModbusTcpProbe covering success and common failures with controlled timeouts and cancellations.
• Integration test using a lightweight mock Modbus server to validate strict mode and RTT reporting.
• E2E test: YAML apply → probe execution → outage open/close → API/CSV verification.

References

• Probes and timeout semantics to mirror: probes‑spec.md.
• Integration points and flow: outage‑probe‑flow‑analysis.md.
• Configuration/Apply/versioning architecture: Configuration.md.
• API and docs surfacing: README.md.
• Scope guardrails for availability‑only emphasis.