HYPERFLEET-608 - fix: Store first adapter status report with Available=Unknown

[rafabene]

Summary

• First status report from an adapter is now stored even when Available=Unknown, so users can see adapter status in the cluster/statuses endpoint while validation is still in progress
• Subsequent status reports with Available=Unknown continue to be discarded (existing behavior preserved)
• Aggregation is skipped for first Unknown reports to avoid affecting cluster/nodepool synthetic conditions

Changes

• pkg/services/cluster.go: Modified ProcessAdapterStatus to allow first Unknown report
• pkg/services/node_pool.go: Same change applied for nodepool
• pkg/services/cluster_test.go: Updated and added tests (4 new test cases)
• pkg/services/node_pool_test.go: Updated and added tests (4 new test cases)

Test plan

• Unit tests pass (383 tests)
• Lint passes (0 issues)
• Verify first adapter status with Available=Unknown returns HTTP 201 and is stored
• Verify subsequent adapter status with Available=Unknown returns HTTP 204 and is discarded
• Verify adapter status with Available=True or Available=False still works as before
• Verify cluster/nodepool synthetic conditions are not affected by first Unknown report

Fixes: HYPERFLEET-608

Summary by CodeRabbit

• Tests

  • Expanded test coverage for adapter status handling, including new test cases to distinguish between first and subsequent status reports with unknown availability conditions.

• Chores

  • Refined internal adapter status processing logic to optimize handling of unknown availability conditions in cluster and node pool status management.

[coderabbitai]

Walkthrough

The PR refines adapter status processing across cluster and node pool services to differentiate between first-time and subsequent reports with "Available = Unknown" condition. When an adapter reports Unknown availability, it now upserts the status on the first report without triggering aggregation, but treats subsequent reports as no-ops. This prevents Unknown conditions from affecting cluster and node-pool level condition aggregation while still recording the initial report. Corresponding test cases were added to verify both first-time and subsequent Unknown condition handling.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Suggested labels

lgtm

Suggested reviewers

• rh-amarin

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and specifically describes the main change: storing the first adapter status report when Available=Unknown, which is the primary objective of this pull request.
Docstring Coverage	✅ Passed	Docstring coverage is 83.33% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

No actionable comments were generated in the recent review. 🎉

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[rafabene]

/retest