Draft device health validation and Influx mapping

[alaurenzi]

What changed

• add strict parsing and normalization for diagnostics ending in /health or /health_status
• validate hardware ID, boot epoch, active faults, cumulative raise counters, and raise/clear timestamps
• remove all health schema-name and schema-version fields and tags
• emit valid health snapshots to dedicated device_health and fault_counter InfluxDB measurements
• derive sparse fault_occurrence points from cumulative counter deltas
• use the lean Influx tag set:
  • device_health: hw_id, device_path
  • fault_counter and fault_occurrence: hw_id, device_path, fault_code
• store boot_id as an Influx field rather than a tag
• expose raise/clear timestamps as Unix epoch milliseconds for direct Grafana date/time formatting
• keep ordinary diagnostics on the existing generic InfluxDB path
• add focused parser and sink tests
• document the health contract and remaining open decisions

Fault occurrence semantics

For each (hardware_id, device_path, fault_code), the sink stores the previous (boot_id, total counter) in memory. A positive counter delta emits one fault_occurrence point whose occurrences field contains the delta. The first sample, a changed boot ID, or a counter decrease establishes a new baseline and emits no occurrence.

Why

Device health diagnostics contain structured fault state that should not be stored as opaque JSON fields. Normalizing them at ingestion gives Grafana stable measurements and makes malformed producer data visible early. The lean tag set preserves the physical device, logical device, and fault dimensions while avoiding redundant series dimensions.

Current assumptions requiring review

1. both /health and /health_status suffixes are accepted
2. device.boot_id is mandatory and counters are monotonic within that epoch
3. optional device-specific health values are added to device_health
4. occurrence baseline state is currently in-memory and resets when the aggregator restarts

Validation

Focused tests cover valid payloads, native and stringified JSON, duplicate keys, missing required values, invalid counters, timestamp validation, consistency checks, lean Influx tags, occurrence deltas, boot changes, counter decreases, and invalid-message omission. Repository CI provides the full integration check.