MachMessageServer: invert the request buffer allocation logic.

The existing implementation used the same logic as is found in
mach_msg_server(), but that logic seems incorrect. When the caller wants
to retry a mach_msg() receive of a too-large message that returns
MACH_RCV_TOO_LARGE, there’s no harm in attempting the receive with a
larger buffer initially. On the other hand, if the caller does not want
to retry such mach_msg() receive attempts, it’s an indication that the
caller is expecting to be intolerant of too-large messages, and there’s
no need to attempt the receive with a buffer any larger than requested.

TEST=util_test
R=rsesek@chromium.org

Review URL: https://codereview.chromium.org/753363003

util/mach/mach_message_server.cc

@@ -112,9 +112,17 @@ mach_msg_return_t MachMessageServer::Run(Interface* interface,
   mach_msg_size_t trailer_alloc = REQUESTED_TRAILER_SIZE(options);
   mach_msg_size_t max_request_size = interface->MachMessageServerRequestSize();
   mach_msg_size_t request_alloc = round_page(max_request_size + trailer_alloc);
+
+  // mach_msg_server() and mach_msg_server_once() invert this condition, but
+  // their interpretation is incorrect. When it is desirable to retry a receive
+  // attempt that returns MACH_RCV_TOO_LARGE with a larger receive buffer, it is
+  // also desirable to use the full receive buffer rounded up to a page size for
+  // the initial receive attempt. On the other hand, when this behavior is not
+  // requested, there is no reason to attempt receiving messages any larger than
+  // expected.
   mach_msg_size_t request_size = (receive_large == kReceiveLargeResize)
-                                     ? request_alloc
-                                     : max_request_size + trailer_alloc;
+                                     ? max_request_size + trailer_alloc
+                                     : request_alloc;
 
   mach_msg_size_t max_reply_size = interface->MachMessageServerReplySize();