bug#64923: 29.1; white background glitch with new graphical frames

[Thiago Melo]

Under the conditions specified below, new graphical frames are
completely white until a redrawing is forced (usually by resizing the
frame):

Emacs built with:

- No toolkit OR Lucid (--with-x-toolkit=no OR --with-x-toolkit=lucid)
- Cairo (--with-cairo)
- Double buffering (--with-xdbe)

Plus:

- Without an X window manager OR using TinyWM
- No toolkit builds: when scrollbar is disabled before creating the frame
- Lucid builds: when scrollbar AND menubar are disabled before
creating the frame

Affects `emacs -Q'.  Tested on Debian GNU/Linux 12.1 (Bookworm).

Issue started happening since commit
e361d0d7e5d3db8575d5d8673012aa4d7448ee54 (Tue Mar 1 20:15:02 2022
+0800, "Add PropertyChangeMask to the standard event set").  Found via
bisect.

Also, out of all (non-toy) window managers I've tested so far
(awesome, dwm, fluxbox, fvwm2, herbstluftwm, i3, twm, xfwm4; all from
stock Debian repository and with default config), only awesome wm
shows direct signs of this issue, and only when set to use floating
windows.  However, in this condition, new frames have a white
background only in areas without text, regardless of theme (more
evident with a dark theme, eg: `M-x load-theme' -> `wombat').

I suspect this issue might be related to bug#64846 as well.