fix(server): recognize the Initiate Multitransport Response on the message channel

[Greg Lamberson (glamberson)]

Summary

handle_message_channel_data unconditionally decoded every PDU received on the MCS message channel as an AutoDetectRspPdu, per a comment claiming the channel "currently carries only the auto-detect response." That is no longer accurate: once a server sends an Initiate Multitransport Request, the client answers on this same channel with an Initiate Multitransport Response (MS-RDPBCGR 2.2.15.2) to report whether it could establish the sideband transport.

MultitransportResponsePdu already has full Encode/Decode support in ironrdp-pdu (with success()/abort() constructors), but has zero consumers anywhere in ironrdp-server. In practice every such response from a real client failed to decode as AutoDetectRspPdu (its securityHeader carries SEC_TRANSPORT_RSP, not SEC_AUTODETECT_RSP) and was dropped with an "Unhandled MCS message channel PDU" warning: legitimate protocol traffic logged as an error.

Reproduced against a real Windows client (mstsc) that offered UDP multitransport but could not establish it: the raw bytes it sent decode exactly as MultitransportResponsePdu { security_header: TRANSPORT_RSP, request_id, hr_response: E_ABORT }.

Changes

• Extracted the message-channel decode into decode_message_channel_pdu, which tries AutoDetectRspPdu first (by far the more common PDU on this channel) and falls back to MultitransportResponsePdu before giving up: this keeps the common case a single decode.
• handle_message_channel_data now has a proper Multitransport arm that logs success/failure at debug level (this is ordinary protocol traffic, not an error condition), instead of falling through to the warn!.
• On a genuine double-decode-failure, the auto-detect error is what's surfaced, since that PDU is overwhelmingly more likely to be the intended one.

Test plan

cargo xtask check fmt/lints/tests/typos/locks all pass.

[github-actions]

This pull request may overlap with #1954.

Both PRs extend ironrdp-server's UDP multitransport support. This one adds decoding and logging of the Initiate Multitransport Response PDU on the MCS message channel; #1954 adds RdpServerBuilder::with_udp_transport plus acceptor-side wiring to offer UDP multitransport. They appear as complementary pieces of the same server-side feature area, which a human should reconcile.

This notice is advisory only. Automated review continues as usual, and how these pull requests relate is for maintainers and authors to decide.

Note

LLM-assisted content (no human feedback).