The problem

During high-churn scenarios, it was observed that pods were sometimes getting scheduled to nodes that did not have the required network devices, causing these pods to become stuck in a failure state.

The root cause was traced to our driver's handling of netlink calls. Under heavy load, the kernel can return partial results for netlink state dumps, indicating this with the NLM_F_DUMP_INTR flag, which the netlink library surfaces as ErrDumpInterrupted. The driver in some cases was processing these incomplete results, leading to the incorrect inclusion of the default network interface in the ResourceSlice.

Although a subsequent sync would correct this, the window was large enough during high churn for the scheduler to assign the default interface as an additional device to the pod.

Solution:

This PR fixes the issue by wrapping the critical netlink call sites with a retry mechanism that specifically handles the ErrDumpInterrupted error. This ensures that the driver always works with a complete and accurate list of network devices from the kernel, preventing the publication of incorrect ResourceSlice information.

The change has the following commits, all of which deal with this replacement

1. refactor: Remove redundant error checks involving netlink.ErrDumpInterrupted
2. feat: Add AddrList to nlwrap handle
3. refactor: Add wrappers for RDMA netlink functions
4. refactor: Replace direct netlink calls with nlwrap
5. feat: Add a wrapper for netlink to retry on ErrDumpInterrupted