Fixes UB of recvmmsg and simplifies signatures of recvmmsg and sendmmsg

[Jan561]

The signature of recvmmsg gets changed to:

pub fn recvmmsg<'a, XS, S, I>(
    fd: RawFd,
    data: &'a mut MultiHeaders<S>,
    slices: XS,
    flags: MsgFlags,
    mut timeout: Option<crate::sys::time::TimeSpec>,
) -> crate::Result<MultiResults<'a, S>>
where
    XS: IntoIterator<Item = I>,
    I: AsMut<[IoSliceMut<'a>]>,

The signature of sendmmsg gets changed to:

pub fn sendmmsg<'a, XS, AS, C, I, S>(
    fd: RawFd,
    data: &'a mut MultiHeaders<S>,
    slices: XS,
    addrs: AS,
    cmsgs: C,
    flags: MsgFlags
) -> crate::Result<MultiResults<'a, S>>
    where
        XS: IntoIterator<Item = I>,
        AS: AsRef<[Option<S>]>,
        I: AsRef<[IoSlice<'a>]>,
        C: AsRef<[ControlMessage<'a>]>,
        S: SockaddrLike,

Fixes #2119

[Jan561]

I've completely disabled the personality::set doctest on my branch as it appears to be completely broken now on multiple platforms at Cirrus

[Jan561]

Thanks for your review, I've also noticed your PR #2140 and applied it to the remaining pointer conversions in both functions (except this one, which is fine imo).

[asomers]

Sadly, there's another merge conflict in CHANGELOG. Could you fix that, please?

[Jan561]

Done. For the sendmmsg-change, I've written a small example of what is possible now, which wasn't possible before.

https://gist.github.com/Jan561/1e44db811698d06bb247c30bbe448fc9

[asomers]

Your gist there suggests that a different API would be more convenient. This is something that I've been thinking about too. It would look something like this:

struct MsgVec<'a> {
    msgvec: Vec<libc::msghdr>,
}
impl<'a> MsgVec<'a> {
   fn with_capacity(n: usize) -> Self {...}
   fn add<S: SockaddrLike + 'a>(&mut self, to: S, I: [IoSlice<'a>], &mut cmsg: ControlMessage<'a>)
   fn reset(&mut self);
}

fn sendmmsg<F>(fd: F, msgvec: MsgVec<'_>, flags: MsgFlags)
    where F: AsFd
    {}

And you could use it something like this:

let mut msg_vec = MsgVec::with_capacity(2);
msg_vec.add(some_host, &[iovec0, iovec1][..], &[ControlMessage::ScmRights(...)][..]);
sendmmsg(&s, msg_vec);

The general idea being that the add API keeps related host, data, and control messages together rather than forcing the user to split them into 3 separate arrays. Plus, the MsgVec::reset method allows reusing storage for a MsgVec, eliminating the need to allocate on each call of sendmmsg, which was the primary problem of the earlier implementation.