fix(lustre-ops): ignore down IPoIB devices during LNet network detection

[dedsec-terminal]

Pre-submission checklist

• I read and followed the CONTRIBUTING guidelines.
• I have ensured that lint, typecheck, and unit tests complete successfully.

Summary of changes

• Added _is_netdev_up(netdev) in lustre_ops.lnet_detection to check the operational state of a network interface via sysfs (/sys/class/net/{netdev}/operstate).
• Added helper _resolve_link_netdev() to decouple RDMA link netdev resolution from filtering logic and maintain low cyclomatic complexity.
• Updated _rdma_interfaces() to check if the detected netdev is operationally up, skipping any interfaces whose operational state is down.
• Added unit test suite TestIsNetdevUp to test operational state checks across various sysfs conditions (up, down, missing files, and read errors).
• Added test_skips_down_netdev in TestRdmaInterfaces to ensure active RDMA devices with down network interfaces are excluded from detected LNet networks.

Justification for changes

When an InfiniBand HCA / RDMA port is ACTIVE with LINK_UP, the corresponding IPoIB network interface (e.g. ib0) may still be administratively or operationally down. Previously, _rdma_interfaces() returned any RDMA device with state == "ACTIVE" and physical_state == "LINK_UP" regardless of the Linux netdev state, causing downstream lnetctl operations to fail when attempting to configure LNet on down interfaces. Checking operstate in sysfs ensures only usable, active network interfaces are returned.

Related Issues, PRs, and Discussions

Fixes #60

Docs

• I confirm that this pull request requires no changes or additions to documentation.

Internal bug fix in LNet hardware interface auto-detection logic.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[dsloanm]

CI failure looks unrelated to code changes: Microceph gave 'hook failed: "storage-attached"'. Will rerun

[dedsec-terminal]

@dsloanm Looks like the rerun hit another env issue. Is there anything you need from me, or do we just need another rerun? Thanks!

[dsloanm]

@dsloanm Looks like the rerun hit another env issue. Is there anything you need from me, or do we just need another rerun? Thanks!

Nothing needed on your end. The changes look good but we're likely being affected by the current outage: https://status.snapcraft.io. I'll start another run once the infrastructure is back up