bug#73752: 29.4; Ligatures are randomly rendered with extra spaces

[Tim Ruffing <dev@real-or-random.org>]

I regularly experience yet another "variant" of this bug. Of course, I
can't be sure that is has the same cause but except for the exact
distortion in the rendering, the circumstances look pretty similar. 

I've seen the bug for a while, and I did some experiments in the past,
but then I got distracted and I didn't find the time to report it
properly. In fact, I see this quite often, and the xuan's test script
makes this very easy to reproduce for me. 

Here's all the meaningful information I could gather in the past. I had
already posted much of this in the mentioned GitHub issue, but let me
repeat here. Also, here a video that demonstrates most the following
items:
https://github.com/user-attachments/assets/56b15dfc-6467-4785-bf1f-f2cd05f33f04
This was recorded on an old Emacs version (should be 29.1, but I can't
vouch for it), but the bug has existed much longer, and I still see it
on my currently installed Emacs 31.0.50 (commit 174784).

 * When I experience that bug, it's not only that there's additional
   spacing at the end of the ligature, but I see this with additional
   spacing after every partial "character" of the ligature (e.g., the
   "===" ligature is rendered rather like "= = = "). For some
   ligatures, this means that individual components are also misaligned
   with respect to each other. For example, the "/" in the "!=" (not
   equal) ligature, which is supposed to strike through the "==" is
   vertically off. (You can see this exact problem in the right half of
   line 58 in the video.)
 * This can happen with all kinds of font changes. So the issue appears
   to be specific to a what I call I "realized face" with selected
   slope, weight, etc. (no idea what the proper Emacs term is).
   Ligatures may be broken in upright but not in italics, or ligatures
   may be broken in bold but not in normal. Once the face is broken, it
   stays broken. 
 * In the video, one can see that searching for "=" fixes the broken
   rendering of the "===" ligature in line 52. Contrary to the previous
   item, I believe this is *not* due to change in background color, but
   due to Emacs trying to highlight the individual "=" char. Still,
   it's interesting to see that this fixes the rendering. (In fact,
   changing the colors doesn't seem to influence the problem. I suspect
   that just the shapes are cached but not the colors?)
 * This one may be a nice for debugging: I use GNOME, and changing the
   font rendering settings triggers a "re-realization" of the fonts,
   and this will then fix the issue (again, see the video). One may be
   tempted to think that this should be a possibility to trigger the
   bug, but I could never observe this. It always fixed the problem for
   me, but maybe I was just "lucky".
 * There doesn't seem to be a way to reproduce this deterministically.
   I made multiple attempts to find a minimal reproducible config and
   fooled myself every time. I don't think this is an elisp config
   thing, I believe it can happen whenever there are ligatures (at
   least on affected systems). I've also tried multiple fonts (Iosevka,
   JetBrains Mono, Fira Code...). The video uses Iosevka.
 * Rebuilding the fontconfig cache with `fc-cache -f` or even `-r`
   doesn't do anything. `(clear-font-cache)` doesn't do anything (see
   video below).
 * Now that I saw this thread, I've also checked (clear-font-cache t)
   and (clear-composition-thread). These don't help.
 * If it's broken in one frame, then it's broken also in other frames. 
 * Notably, I also use the pgtk build on wayland. 
 * I have found this on the web, which seems yet another variant (?) of
   the bug:
   https://web.archive.org/web/20230226082659/https://www.reddit.com/r/emacs/comments/11c957r/ligatures_character_overlap_and_extreme_squashing/

I've just managed to reproduce this again, and I've attached gdb, but
I'm also stuck at pp doesn't displaying:
(gdb) pp composition_gstring_from_id(19)
(gdb) p composition_gstring_from_id(19)
$6 = (struct Lisp_X *) 0x58ad4d938225
(gdb) xpr
Lisp_Vectorlike
PVEC_NORMAL_VECTOR
$7 = (struct Lisp_Vector *) 0x58ad4d938220
{XIL(0x58ad4f32aabd), make_fixnum(19), XIL(0x58ad4d93f8e5),
XIL(0x58ad4d93f93d), XIL(0x58ad4d93f995)}

I still have the session open. Also happy to rebuild with more debug
info enabled, if you tell me how that works.

```
3.24.43, cairo version 1.18.2) of 2024-09-13 built on tonno.fritz.box
Repository revision: 04e8ad6489ebec121ace7ea6d582429a96af8f04
Repository branch: makepkg
System Description: Arch Linux

Configured using:
'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
--localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games
--with-modules --without-m17n-flt --without-gconf
--with-native-compilation=yes --with-xinput2 --with-pgtk
--without-xaw3d --with-sound=no --with-tree-sitter --without-gpm
--without-compress-install
'--program-transform-name=s/\([ec]tags\)/\1.emacs/'
'CFLAGS=-march=native -O2 -pipe -fno-plt -fexceptions
-Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security
-fstack-clash-protection -fcf-protection -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer -g
-ffile-prefix-map=/home/tim/.cache/pikaur/build/emacs-
git/src=/usr/src/debug/emacs-git
-flto=auto' 'LDFLAGS=-Wl,-O1 -Wl,--sort-common -Wl,--as-needed
-Wl,-z,relro -Wl,-z,now -Wl,-z,pack-relative-relocs -flto=auto'
'CXXFLAGS=-march=native -O2 -pipe -fno-plt -fexceptions
-Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security
-fstack-clash-protection -fcf-protection -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer -Wp,-D_GLIBCXX_ASSERTIONS -g
-ffile-prefix-map=/home/tim/.cache/pikaur/build/emacs-
git/src=/usr/src/debug/emacs-git
-flto=auto''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER PGTK PNG RSVG SECCOMP SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP XIM GTK3 ZLIB
```