intellihide: enable/disable unredirect when dock shows/hides

[taoky]

This PR tries to workaround #1381 by explicitly disabling unredirection when dock shows (_animateIn), and restoring (_animateOut) when it hides in intellihide mode.

Although there have been extensions disabling unredirection when they are enabled to workaround the glitch, users might still find their dock flickering after:

• They start some games rendering at full-screen, and exit;
• or, plug in and out their external displays for several times.

(This looks like a bug in gnome-shell, but I could not find a reliable way to trigger this.)

In mutter (src/compositor/compositor.c), {disable,enable}_unredirect_for_display controls the counter disable_unredirect_count, and it is used to control whether the compositor is "unredirect inhibited" or not. A similar counter is used here, and is intended to avoid unexpected unredirect enablement. Also note that it is impossible for extensions to know whether unredirection is disabled or not, as this counter is private.

I was worrying about manually disabling/enabling unredirection might affect performance before, but it looks like Meta.{disable,enable}_unredirect_for_display is also used for many components in gnome-shell JavaScript code, so this might not be an issue.

I have tested this for ~2 weeks on my laptop (with no other extensions controlling unredirection) and it works without glitches. This might still need more tests, and the code in patch might not be optimal.

[3v1n0]

Can't we just do it this once on animation start and then onComplete?

[taoky]

Currently it disables unredirection before dock shows (in _animateIn) and enables after it hides (in _animateOut's onComplete). The dock glitch is triggered when dock's shown on screen above the app, unredirection is not disabled, and mutter thinks it shall let the app show in an unredirection way. Thus I think that enable_unredirect_for_display and disable_unredirect_for_display should only be triggered when the dock is hidden.

I would agree that the counter used here is too inelegant... Maybe a boolean is enough.