Auto-generate catch-and-default-reply wrappers for Swift IPC receivers

Component: WebKit IPC Infrastructure | 6055228

WebKit's UIProcess, Networking and GPU processes receive IPC messages from the sandboxed, potentially compromised WebContent process; messageCheck validates message arguments before handler code runs. Any message expecting a reply must send something back even on validation failure, or the sender blocks forever — so each Swift receiver hand-wrote a default reply value for the failure path, and a reply's Swift signature could quietly diverge from the fallback value standing in for it.

This commit generates that catching and default-reply logic directly from the .messages.in schema for all Swift-based receivers. The generated wrappers live on the receiver's WeakRef class, take an IPC::Connection uniformly, and call a generated completeWithDefaultReply() when messageCheck validation fails on a message expecting a reply. The connection-argument marshaling in handleMessageAsync is normalized to match handleMessage and handleMessageSynchronous.

Significance

Hand-written default replies could drift from the reply signature they stand in for; generating them from the .messages.in schema removes that drift by construction. Message validation on IPC handlers is a sandbox-boundary security control, and the failure path of that control is exactly the code least likely to be exercised by tests.

Audit directions

The pattern to carry forward is a security control whose failure path is hand-written per call site. Narrow: the connection-argument marshaling in handleMessageAsync now matches the other two dispatch paths, so any remaining receiver that threads a connection differently is the odd one out — enumerate them. Wider: the C++ IPC receivers have the same validation-failure obligation and have not been through this codegen pass; audit the hand-written default replies there for divergence from their reply signatures, and for failure paths that return without replying at all. Widest: wherever a protocol requires a response on both success and failure, the failure branch is the one with no integration test behind it — generating it from the same schema that defines the success branch is the general remedy. Code-review tell: a literal default value inside a validation-failure branch, adjacent to a reply completion handler whose type is declared elsewhere.

---