docs: firmware-update design, NIC discovery findings, and ConnectX-6 slice

[shyamsundart14]

What

Adds design documentation for GitOps-driven firmware updates, driven entirely through Redfish UpdateService.SimpleUpdate (no vendor consoles):

• docs/firmware-update-design.md — full design for per-component firmware updates (BIOS, NIC, StorageController, HardDrive, PSU) across a heterogeneous Dell/HPE/Lenovo fleet, scoped per building block.
• docs/nic-discovery-findings.md — findings from a live NIC discovery field-consistency probe across 15 Dell/HPE/Lenovo servers.
• docs/firmware-update-slice-connectx6.md — ConnectX-6 vertical slice.

Why

Documents the approach for replacing vendor-console-driven firmware management (OneView / OME / LXCA) with a Redfish-direct, GitOps-driven operator.

Notes

• Docs only — no code or manifest changes.
• Draft: opening for early design review.

[afritzler]

A few comments from my side:

We already have a BIOSVersion and a BMCVersion resource which essentially should do the upgrade of those component versions. https://github.com/ironcore-dev/metal-operator/blob/main/api/v1alpha1/bmcversion_types.go and https://github.com/ironcore-dev/metal-operator/blob/main/api/v1alpha1/biosversion_types.go. So now comes the catch: we are migrating those resources now to the metal-maintenance-operator. Here we are starting with the ServerMaintenance (ironcore-dev/metal-operator#987).

Now when it comes to the firmware component updates: We could actually use this migration effort and redefine how this is done. @nagadeesh-nagaraja et al. who worked on the previous types need to be involved here.

Regarding your proposal:
After looking into the types you proposed: I am not sure if it is a good idea to start with a composite type for all firmwares of a Server + updating them via a selector over a fleet of machines. I would rather maybe start with updating one firmware on one host first.