distinguish real damage events from refresh requests

[Antoine Martin]

At the moment, we only skip calls to damage() that are tagged as polling events by the gtk shadow server base class.

And this is only used:

• by the rfb server for basic rate control: skipping events if the encoding queue is busy
• for not recording damage events statistics

Problem is that there are many other places where we can generate damage calls:

• refresh which is already tagged
• window map and configure events

etc.

The damage events list is used for some heuristics, but clients may send many configure events (ie: when moving a window), which can completely skew the data we rely on.

[Antoine Martin]

r21014 skips recording damage events for shadow servers, but this is the wrong place and assumes that shadow servers don't get damage events - which is true for now, but this may change.

[Antoine Martin]

There are also tricky issues with shadow servers and video region detection, see r21019 backport. Well hidden in there: we happen to avoid downscaling shadow screens as a very fortunate side effect!

For some things we want to know how many times we go through the damage function, for others we only care about real screen updates triggered by changes on screen.
Shadow servers are a special case: we poll and trigger refreshes, but we still want to use video encoders, and for the full window area...

[Antoine Martin]

This would help with #2044

[Antoine Martin]

See also #2049.

Updates:

• r21038: don't count auto-refresh and polling damage events
• r21050: only actual damage events will be recorded as damage statistics