src/common: Do not assert on truncated buffers

[sydidelot]

This patch replaces an assertion with proper error handling when a truncated control buffer is detected, returning an error to the caller instead of crashing the process.

We observed crashes in debug builds of libfabric in the zero-copy code path when async send operations complete. The crash occurs when the kernel reports a truncated control message, triggering an assertion.

According to the recvmsg(2) man page, msg_controllen should be updated on return to reflect the length of the received control data. However, GDB shows that the buffer is allocated with 48 bytes and msg_controllen remains unchanged after recvmsg() returns, suggesting that truncation should not have occurred.

The root cause is currently unknown, and there is no clear evidence that increasing the control buffer size would resolve the issue. The zero-copy implementation matches existing implementations (e.g. QEMU, SPDK, and Linux kernel unit tests).

Until the underlying issue is better understood, avoid asserting on truncated buffers and handle the condition gracefully by returning an error to the caller. This results in the endpoint being closed and the error reported back to the application.

[sydidelot]

If preferred, I can remove the return statement and let the function consume the data, though I'm not sure about the implications.