ironrdp-server: client's MultifragmentUpdate MaxRequestSize is ignored, Jump Desktop drops on the first bitmap update #2122

RdpServer never reads the client's Multifragment Update Capability Set. The update encoder is always given the server's own max_request_size (8 MB by default):

and splits bitmaps against that value:

MS-RDPBCGR 2.2.7.2.6 defines the client's MaxRequestSize as the size of its reassembly buffer: it "places a cap on the size of the largest Fast-Path Update that can be fragmented (there MUST always be enough buffer space to hold all of the related Fast-Path Update fragments for reassembly)". The FreeRDP server notes the same, the client "is completely free to accept our proposed max request size or send a different value ... and we have to accept that":

https://github.com/FreeRDP/FreeRDP/blob/cfa8e3a98ca25923aa0c96d364e6f96c0b7ac85f/libfreerdp/core/capabilities.c#L2884-L2893

Jump Desktop (macOS, 10.15.40) sends MaxRequestSize = 65536 and no Surface Commands, so it gets legacy bitmap updates. The first full-screen update is far larger than 64 KiB, and it drops the connection:

ERROR [rdp_core] FastPath: Not enough space in the reassembly buffer
ERROR [rdp_core] rdpc_process_fastpath_update failed

Reproduced with the server example on master (plus #2119, so Jump Desktop gets past the Demand Active) sending full-screen 1920x1080 updates: Jump Desktop disconnects on the first update. Seen first through Warpgate 0.30.0-beta.1, which vendors ironrdp-server 0.13.0.

Proposed fix: hand the encoder the smaller of the server's and the client's MaxRequestSize, keeping the server's when the client sends no capability set or a zero size. The encoder already splits bitmaps against the value it is given; with that change the same setup stays connected (strips of 1920x8, about 49 KB each). Happy to open a PR with this.