Regression with GLAMOR in Xwayland 23.2.4 and master

Summary

Issue was reported upstream initially in vim as https://github.com/vim/vim/issues/14233 and was pointed to me privately.

Visual glitches appear in gvim when running in Xwayland. The issue does not occur when GLAMOR is disabled or when running gvim on Wayland natively.

Steps to reproduce

1. Start Weston (easier to reproduce, but affects all compositors the same)
2. Open a large file in gvim (aka vim-X11)
3. Select the whole text, press U (capital U) to put everything uppercase
4. Resize the gvim window, some portion of the window start to appear transparent
5. If step 4 did not trigger the issue, retry from step 3, using u to put everything lowercase
6. Repeat as needed

Additional data

As it turns out, this is a regression in Xwayland that first appeared between xwayland 23.2.3 and 23.2.4.

A bisection in git pointed at the following commit:

2236e3fda2cbae61e87d679ce59fed8d5b0d08d is the first bad commit
commit 02236e3fda2cbae61e87d679ce59fed8d5b0d08d
Author: Michel Dänzer <mdaenzer@redhat.com>
Date:   Fri Jan 5 18:31:11 2024 +0100

    glamor: Don't override source alpha to 1.0 if it's used for blending
    
    It caused an incorrect result of the blend operation.
    
    Use glColorMask to prevent non-1.0 alpha channel values in a depth 32
    pixmap backing an effective depth 24 window. For blending operations,
    the expectation is that the destination drawable contains valid pixel
    values, so the alpha channel should already be 1.0.
    
    Fixes: d1f142891ef3 ("glamor: Ignore destination alpha as necessary for composite operation")
    Issue: https://gitlab.gnome.org/GNOME/mutter/-/issues/3104
    (cherry picked from commit d1bbf82d72566e16e90800c77cf70fe5fc4ef2e8)

 glamor/glamor_render.c | 28 +++++++++++++++++++++++++++-
 1 file changed, 27 insertions(+), 1 deletion(-)

/cc @daenzer @vstinner