Xpra: Ticket #1754: present_fbo vsync delays sending paint acks

Discovered as part of #999 / #1688: with double-buffering, present_fbo / gl_show will wait for vsync when swapping the buffers, which means that we will only send the paint ack after up to ~17ms on a 60Hz display. If we send a number of consecutive flushed paints, they can often be decoded very quickly but the actual screen update will be rate limited by the vsync... This makes it look like we have bandwidth problems when in fact it's just bad scheduling of screen updates.

Potential solutions:

• rate limit the sending of damage packet groups: hard, because the batch delay fluctuates a lot - maybe we can ensure that we always wait at least 1/vsync? (also we only want this rate limit when sending a fair number of screen updates - punctual ones don't need to wait..)
• send the acks before the vsync: the rate limiting would still be there, not sure this would help at all
• allow new paints to update the fbo: can't be done since we need the UI thread to access the context, used by the swap buffers