MachMessageServer: don’t deal with MACH_SEND_TRAILER

MachMessageServer: don’t deal with MACH_SEND_TRAILER.

As documented, MACH_SEND_TRAILER would allow a sender to provide its own
message trailer instead of having the kernel append its own
kernel-generated trailer. This is a Mach feature that supports a network
of multiple Mach hosts, but even in that environment, the option is
restricted to use by privileged callers. In reality, MACH_SEND_TRAILER
has never been implemented in OS X.

The system’s mach_msg_server() family does consider the value of
MACH_SEND_TRAILER, but this is pointless. Any purported trailer set by a
server function would be ignored.

Maintaining this code gives the illusion that it’s functional, so it’s
being removed.

TEST=util_test MachMessageServer.*
R=rsesek@chromium.org

Committed: https://chromium.googlesource.com/crashpad/crashpad/+/306625dac4df93af8ef014986fd5c34bdcc14d42

[Mark Mentovai, 2014-11-24 23:12:05]

mark@chromium.org changed reviewers:
+ rsesek@chromium.org

[Robert Sesek, 2014-11-25 19:32:42]

LGTM. Where'd you find that this was supposed to be fore networked Mach hosts?

[Mark Mentovai, 2014-11-25 19:59:33]

This breadcrumb in
https://opensource.apple.com/source/xnu/xnu-2422.115.4/osfmk/man/mach_msg.html:

> If set, the kernel, instead of determining the message attributes
> itself, will accept a formatted message trailer from the sender. The
> supplied trailer must be of the latest version supported by the
> kernel, and must contain all message attributes defined by the
> kernel. Only tasks with a security ID of KERNEL_SECURITY_ID can use
> this option; the intended use of this option is in support of the
> Net Message server.

[Mark Mentovai, 2014-11-25 20:00:16]

Committed patchset #3 (id:40001) manually as
306625dac4df93af8ef014986fd5c34bdcc14d42 (presubmit successful).