Verify no framebuffer update requests are sent in touchpad mode

[bk138]

re #125 #78

• [x] centralise cl->updateRect setting as far as feasible
• [x] add updateRect setter/getter to lib
• [x] change server so that it respects indicated rect on cursor movement updates -> made a follow up in https://github.com/LibVNC/libvncserver/issues/586
• [x] merge to multicast
• [x] update submodule
• [x] use getter/setter

[bk138]

outcome: they are still sent, altough #78 tried to prevent this.

the problem

• is that libvncclient is using SupportsClient2Server() checks to shortcut certain functions to do nothing
• which is checking client->supportedMessages
• supportedMessages is used on the libvncserver side to declare caps of the server and inform clients via SupportedMessages encoding
• on the libvncclient side, however, we kinda unconditionally set the bitsets via DefaultSupportedMessages() and add more if we encounter a Tight or Ultra server. The bad thing is these bitset settings happen after rfbGetClient() and in fact after the first few messages are exchanged.

insights

• learning 1: supportedMessages on the client if set initially get overridden by the lib :-/
• learning 2: supportedMessages are not only set by DefaultSupportedMessages() but at least once also on receipt of certain messages (xvp being one case)
• learning 3: supportedMessages on the client are the only thing evaluated by the lib's functions to decide whether or not to do something :-/

questions

• ❗ is supportedMessages actually the right place to save the lib user's intent? or is it rather just for managing state depending on the server?
  • 💡 if it's more the latter, it'd be better to handle cl.appData info in libvncclient's functions directly and in addtion to supportedMessages
  • this works as a PoC, but input is then cut off as the remote fb dimensions are not known...
  • 💡💡 i.e.: serverinit message conveys w,h correctly, but later on the client is not notified about fb size changes
  • SendFramebufferUpdateRequest called in reaction to newfbsize and similar events -> rather rare -> limit calls to SendIncrementalFramebufferUpdateRequest which are done at the end of every HandleRFBServerMessage()
• one stupid way out would be to save intent via rfbClientSetClientData(), then set supportedMessages from this all the time 😐
• why not simply modify supportedMessages after rfbInitClient()?
  • already doing this, but the Tight-specific DefaultSupportedMessagesTight() gets called later when a sectype is received, overwriting this
  • remove DefaultSupportedMessages() call from DefaultSupportedMessagesTigh() and ultra-counterpart?
    • ❗ yeah, would be possible w/o side effects ✅
• what about making DefaultSupportedMessages() configurable via cl.appData or the like?
  • app would have to set cl.appData for the init case
  • then for runtime switching app would have to modify supportedMessages
  • two different APIs for the same thing, depending on client state 🤯