fix(connector): handle ServerDeactivateAll during CapabilitiesExchange

[Anton Isaiev (totoshko88)]

Some RDP servers (notably GNOME Remote Desktop / grd) send a ServerDeactivateAll PDU before ServerDemandActive during the initial Capabilities Exchange phase. This is valid per MS-RDPBCGR §1.3.1.3 (Deactivation-Reactivation Sequence).

Previously this caused a hard error:
"unexpected Share Control Pdu (expected ServerDemandActive)"

Now the connector skips the DeactivateAll and waits for the next PDU.

Fixes #1253

[Greg Lamberson (glamberson)]

Thanks for picking this up Anton Isaiev (@totoshko88). The fix is correct as written: the explicit self.state = ConnectionActivationState::CapabilitiesExchange { ... } before the early return is necessary because mem::take(&mut self.state) at the top of step() has already replaced the state with Consumed, and the normal self.state = next_state assignment at the bottom of the function is bypassed by the early return.

The spec read is also reasonable. MS-RDPBCGR §1.3.1.3 frames the Deactivation-Reactivation Sequence as a post-completion server-initiated reactivation, so a server sending DeactivateAll during the initial connection is technically nonstandard. The "skip and wait" approach this PR takes is the conservative interoperable interpretation: treat the inbound DeactivateAll as the start of a reactivation, stay in CapabilitiesExchange, and let the next DemandActive arrive normally.

Two small suggestions a reviewer is likely to ask for:

1. A test for the new behavior. A connector-step test that feeds a ServerDeactivateAll PDU during CapabilitiesExchange and asserts the state stays at CapabilitiesExchange { io_channel_id, user_channel_id } and Written::Nothing is returned would lock this in. A follow-on assertion that feeds a normal ServerDemandActive immediately after and shows the connector transitions to ConnectionFinalization would cover the full GRD pattern end to end.

2. A short comment noting that the decoded PDU is intentionally discarded. Something like:

// Drop the decoded share_control_ctx: the DeactivateAll body carries
// no payload we need during initial activation, and the channel-id
// mismatch warning above has already fired if applicable.

This is downstream of relevance to Lamco's GNOME Remote Desktop interop work, where this connector-side error has been blocking client-side testing against GRD. Worth flagging that #1232 (GlassOnTin) reports a cousin failure mode with the same unexpected Share Control PDU error string family but a different root cause: the server closing the connection during capabilities exchange rather than sending DeactivateAll. That one is not addressed by this PR and remains a separate work item. Calling it out so a reader of #1232 finds their way here and does not assume the two cases overlap fully.

[Anton Isaiev (totoshko88)]

Thanks for the review Greg Lamberson (@glamberson)! I've addressed both suggestions:

1. Added a comment noting the decoded PDU is intentionally discarded — clarifies that the DeactivateAll body carries no payload needed during initial activation.

2. Added tests for the new behavior:

• deactivate_all_during_capabilities_exchange_stays_in_same_state — feeds a ServerDeactivateAll PDU during CapabilitiesExchange and asserts the state remains unchanged with Written::Nothing returned.
• demand_active_after_deactivate_all_transitions_to_connection_finalization — feeds ServerDeactivateAll followed by ServerDemandActive and asserts the connector transitions to ConnectionFinalization, covering the full GRD pattern end to end.

[Greg Lamberson (glamberson)]

Thanks Anton Isaiev (@totoshko88), both items look right. The comment captures the "body decoded but discarded" rationale cleanly, and the tests cover the case that was breaking GRD interop.

No further comments from my side.

[Benoît Cortier (CBenoit)]

LGTM! Thank you both!