GUACAMOLE-1969: Implement recording-include-clipboard connection parameter

[lukasraska]

This PR introduces new recording-include-clipboard into all supported protocols that dumps the clipboard instruction, along with the relevant stream blobs, into recording.

Few key notes:

• because clipboard can contain sensitive data, it's opt-in in the same way as recording-include-keys and administrators need to explicitly set the parameter to true
• as the recording components are responsible for handling the recording dumps, guac_recording_create includes the new parameter (i've opted for making it the last argument, but let me know if I should switch it to be next to the include_keys)
• the keyboard dumps are hooked into user clipboard handler, so should only handle changes from user side and not from the server side
• as clipboard instruction merely creates stream, even the simplest paste is essentially at least 3 instructions (clipboard, 1+ blobs, end), which can be seen like this in some testing recording

$ sed 's/;/\n/g' recording-clipboard | grep clipboard -A 2
9.clipboard,1.0,10.text/plain
4.blob,1.0,20.UHVsbCBjb21wbGV0ZQ==
3.end,1.0

Once this PR is approved from technical perspective, I will create respective PRs for guacamole-client and guacamole-manual to accomodate for both documentation change as well the client side option

[necouchman]

A handful of places where I think some copy-pasta slipped in and got replicated across all of the files you modified. Other than that, I think this looks good.

[necouchman]

Is it only "paste" data, or would it also include copy events?

[lukasraska]

As of now, it only reports paste data -> those within the user-originating clipboard blobs. I aimed this to give better insight into what is the actual data transfered in, since currently if somebody pastes some command via clipboard, it's not really visible in the recordings (merely the UI changes are rendered, whatever happens based on that).

If also server-originating clipboard changes should be logged, from brief check it should probably be easy to hook it up to __send_user_clipboard (or probably the respective method that calls this for each connected user), but that recording could get quite big in such cases (so if this would be desired, I would probably aim for two separate args, like with the disable-copy/paste options, so users can choose which one to log.

[necouchman]

In that case, I wonder if it would be worth changing the overall parameter name to better reflect what we're capturing, in case we do want to add something different in the future. Your point about the size of the recording capturing certain clipboard data is well-taken, and I'm not sure it makes sense to add that (now), I just think we want to be very clear about what data we're capturing.

[lukasraska]

Sure, what would you suggest as an appropriate parameter name? recording-include-clipboard-paste / recording-include-user-clipboard or something else? I'm not sure how long these args can be in practice and I would like to avoid overly long parameter names, but then it should be fairly descriptive as you mention. Thanks