When [Wayland][WebRender] is used Firefox shows heavy flickering during scale changes.

Scale change can happen in multi-monitor scenario when a window is moved on screen edge and window decorations/shadows touch another monitor.

From my debugging of a similar issue, Firefox will commit a new buffer scale immediately when firefox is moved between screens. Instead, it should render a new buffer, set new buffer scale, and commit the surface.

I managed to reduce some flickering but the main issue is that content (child) process updates the web content slowly so we need to pause compositor and resume it when web content is reflown/composited for the new scale/size.

• Set mozcontainer scale only when we're going to paint into it.
• Set scale to EGL window with window size update at nsWindow::SetEGLNativeWindowSize().
• Don't fire configure events for scale changes as we handle scale change by OnScaleChanged().
• Remove redundant layout updates from nsWindow::OnScaleChanged().
• Dont pass allocation size to OnScaleChanged() as it's not provided by the Gtk signal.
• Log updates

We need to track window compositor state in various cases, when compositor is paused after window creation,
when compositor is paused for hidden window (EGLSurface is missing) and paused compositor when layout is not updated yet
and drawing will lead to incorrect / obsoleted window content.

In this patch we track compositor state by WindowCompositorState atomic enum (because it can be accessed from Compositor thread)
and two private methods (PauseCompositorHiddenWindow and ResumeCompositorHiddenWindow) and two public ones (PauseCompositor() and ResumeCompositor).

Private interface is used by nsWindow when EGLSurface is missing so we can't render to window - it's initial compositor pause and
pause when window is hidden.

Public interface is used by nsWindow and WebRender compositor to disable/enable rendering when window content is updated.
When compositor is disabled by public interface it will be enabled automatically after a timeout (1s) or when content layout is updated.

Changes in the patch:

• Implement GtkCompositorWidget::RemoteLayoutSizeUpdated() to notify GtkCompositorWidget widget about layout size update in content process.
• Track nsWindow compositor state by WindowCompositorState
• Implement nsWindow::PauseCompositorHiddenWindow() and ResumeCompositorHiddenWindow() to handle internal nsWindow states.
• Implement nsWindow::PauseCompositor() and nsWindow::ResumeCompositor() to allow compositor pause/resume during content layout updates.
• Use timeout to resume compositor paused by public interface as a fallback when content is not updated or it takes too long.

Depends on D121649

try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=6bcbcc65188a694d8873415af22f0de9e1512f00

nsWindow on Linux is accessed from Compositor thread so we need to make it thread safe.

Depends on D121650

GtkCompositorWidget and WindowSurfaceWayland objects are used in Compositor thread and we should hold reference to nsWindow to make sure we don't release nsWindow early.

Depends on D122072

try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=988d1c6f5cb6182272087c9b8c2366a1c8c472b0

https://hg.mozilla.org/mozilla-central/rev/e6c2db2577d0
https://hg.mozilla.org/mozilla-central/rev/d4a6fa9f6a20
https://hg.mozilla.org/mozilla-central/rev/36ab9d576d1b
https://hg.mozilla.org/mozilla-central/rev/87059d602102

Robert, as this landed in 93 you may need to re-introduce the hack for Wayland compositor.

Thanks, will do!