Draft: [th/platform-netlink-ctrunc] platform/netlink: don't reallocate ancillary data for recvmsg() on truncation

Coverity thinks there is a problem here:

    Error: TAINTED_SCALAR (CWE-20): [#def233]
    NetworkManager-1.31.5/src/libnm-platform/nm-netlink.c:1437: tainted_argument: Calling function "recvmsg" taints argument "msg".
    NetworkManager-1.31.5/src/libnm-platform/nm-netlink.c:1458: tainted_data: Passing tainted expression "msg.msg_controllen" to "g_realloc", which uses it as an allocation size.
    NetworkManager-1.31.5/src/libnm-platform/nm-netlink.c:1458: remediation: Ensure that tainted values are properly sanitized, by checking that their values are within a permissible range.
    # 1456|
    # 1457|           msg.msg_controllen *= 2;
    # 1458|->         msg.msg_control = g_realloc(msg.msg_control, msg.msg_controllen);
    # 1459|           goto retry;
    # 1460|       }

but the problem is not the tainted data. The problem is how should we handle MSG_CTRUNC? If we reach MSG_CTRUNC we already lost data. Retrying to receive the next message is not going to fix that and is plain wrong.

Also, there really is on need why any truncation should happen. The only ancillary data that should be present is the sender information, and for that our buffer is supposed to be large enough.

So, simply ignore truncation. It shouldn't happen, if it happened we cannot recover from it (aside failing an assertion), and all we really care are the retrieved credentials. If truncation happened, we might not have retrieved the credentials, but then that is for the caller to handle.