Replace mem::zeroed with mem::MaybeUninit::uninit for large struct in Unix

[xizheyin]

As discussion in #136737.

• Replace mem::zeroed() with MaybeUninit::uninit() for sockaddr_storage in accept() and recvfrom() since these functions fill in the address structure
• Replace mem::zeroed() with MaybeUninit::uninit() for pthread_attr_t in thread-related functions since pthread_attr_init() initializes the structure
• Add references to man pages to document this behavior

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @thomcc (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[joboet]

I thought about this a bit. We probably can't use .assume_init() as often as I thought since the C libraries neither guarantee that the structure can be moved, nor that it is fully initialized.

[bors]

☔ The latest upstream changes (presumably #136954) made this pull request unmergeable. Please resolve the merge conflicts.

[xizheyin]

That makes sense! I have removed assume_init. As far as I understand it, there is no difference in program behavior between using as_mut_ptr/as_ptr directly and using assume_init, but there is a difference in terms of intent. One does not assume that C performs the initialization, the other assumes that C must perform the initialization. So, we should just pass the pointer to C's API, and then C fills it, and it's not up to us to consider whether it's init or not. Is that correct? @thomcc