Make mqueeue objects work across a fork again.

[imp]

Summary

In r110908 (2003) alfred added DFLAG_PASSABLE to tag those types of FD
that can be passed via unix pipes, but mqeueuefs didn't exist
yet. Later, in r152825 (2005) davidxu neglected to include
DFLAG_PASSABLE sincee people don't normally pass thesee things via
unix sockets (it's a FreeBSD implementation detail that it's a file
descriptor, so why would they nootice). Then r223866 (2011) by
jonathan used the new flag in fdcopy, which fork uses which is where
mqueuefs actually broke mqueue objects being propagated by fork. Fix
this by tagging mqueuefs as passable as well. POSIX requires this to be the case as well.

PR: 243103

Test Plan

The test case in the bugzilla fails before this change and works after. Based on the history here, I'm sure this was an innocent oversight on David Xu's part which became noticeable after r223866 (jonathan didn't intend for this to be fallout based on the commit messagee) and it is correct (or r223866 is bogus for reusing this flag)

[kib]

I am not sure if mq_notify() stuff would interact with fork and now pass for SIGEV_THREAD would handle this.

[jilles]

The mq_notify() mechanism indeed needs to be considered here, but I think it already handles that:

• the kern_kmq_notify() code knows to tie a registration to a particular process and file descriptor number;
• if a process closes an mq file descriptor, the registration (if any) it made to that descriptor number is removed;
• if a process exits, all registrations it made are removed.

When using rfork() to share the file descriptor table between two processes, it appears to be possible (from code inspection, untested) that one process registers a notification, the second process closes the descriptor and the notification stays. This need not block this review.