feat(connector): implement multitransport bootstrapping handshake

[glamberson]

This is a design proposal — looking for feedback on the API approach before wiring up the async/blocking drivers.

Makes the MultitransportBootstrapping state functional instead of a no-op pass-through.

After licensing, the server may send 0, 1, or 2 Initiate Multitransport Request PDUs before starting capabilities exchange. This PR reads those PDUs by peeking at the BasicSecurityHeader flags (SEC_TRANSPORT_REQ), then pauses in a new MultitransportPending state so the application can establish UDP transport (RDPEUDP2 + TLS + RDPEMT) or decline.

The API follows the existing should_perform_X() / mark_X_as_done() pattern used by TLS upgrade and CredSSP:

• should_perform_multitransport() — true when requests have been collected
• multitransport_requests() — access the server's request PDUs
• complete_multitransport(responses, output) — send response PDUs, advance
• skip_multitransport() — decline, advance

Open question: the Demand Active PDU that signals the end of multitransport bootstrapping arrives while we're still in MultitransportBootstrapping. When the connector transitions to MultitransportPending, this PDU needs to be buffered and re-fed after the application completes. Two options:

(a) The driving code (ironrdp-async/ironrdp-blocking) buffers the PDU externally and re-feeds it. This keeps the connector stateless w.r.t. buffering but requires changes to connect_finalize().

(b) The connector buffers the PDU internally in MultitransportPending and replays it when complete_multitransport() / skip_multitransport() is called. This is self-contained but adds buffer state to the connector.

I've gone with (a) in this draft — the connector doesn't buffer. Feedback on which approach is preferred would be helpful before wiring up the async/blocking drivers.

Builds on: #1091

Related: #140

[glamberson]

I really need feedback on this so I'll take the draft status off and see where we get.

[Benoît Cortier (CBenoit)]

Hi! Good job. I need a little bit more time to dig into this and craft a well thought answer. I’ll come back to you in the next 24h.

[glamberson]

Hi! Good job. I need a little bit more time to dig into this and craft a well thought answer. I’ll come back to you in the next 24h.

Thanks! Great! Yes this is pretty important so I knew it would take some time. Much appreciated.