Remove client-server shortcut paste code

[matt335672]

Fixes #1839

@jsorg71 - I'd appreciate your feedback on this PR. Are I missing something obvious?

When significant amounts of data is coming from the client in a fragmented CLIPRDR_DATA_RESPONSE PDU, this code provides a way to start copying it to a requesting client before it is all read.

The only advantage of this code is to provide a slight speedup before a paste is visible on the server.

There are significant problems with this code. Notably, it is very difficult to parse Unicode text coming through this route. Each UTF-16 character can occupy up to 4 bytes, and a fragmentation boundary could occur at any point within a UTF-16 character.

[matt335672]

In the absence of any feedback I'm going to merge this change as it fixes a customer problem. Happy to revert if it proves necessary.

[jsorg71]

Hi Matt, Sorry for delay,
I think you can see what this ss code was doing. The clipboard channel chunks out clipboard data to transmit, the X11 clipboard chunks out data to transfer between X11 clients. Hook them up so the app starts getting data right away. Seems great except you need to know the size in the beginning and converting UTF 16 to UTF 8 you can not know the size. I did notice you can guess the size too small but guessing too large hangs X. We could get around that by dumping zeros at the end maybe.
I think it's ok to just remove it. If we need something like this back, we can improve on it.

[matt335672]

I got the gist of the code. The main problem I had was more related to #2603 rather than the size. Addressing #2603 means coping with UTF-16 characters being either 2 or 4 bytes (e.g. 😥 maps to 0x3d 0xd8 0x25 0xde in the byte stream). Converting that to UTF-8 on the fly in the ss code means caching up to 3 bytes potentially when we hit a fragmentation point. It's doable, but messy.