Bug 2237562

I spent several hours today unable to access my email locally (I use neomutt to access notmuch queries), after having run dnf update.  After some trial and error, I was able to narrow the problem down to the fact that glib2's ini parser functions regressed in functionality.  My ~/.notmuch_config file contained something akin to this (edited to protect the innocent):

[query]
foo = ( from:example.com or from:"/.*\.example\.org/" )

which allows me to do things like 'notmuch search query:foo' to see all emails from the example.com domain as a literal string, and from any subdomain of example.org via a regex.  But with today's update in library, glib's ini parser now treats that line as invalid, and completely chokes on parsing the file, at which point notmuch was not able to proceed any further, with bizarre results.  For example, 'notmuch config list' was printing no output but exiting with status 0 (so it may ALSO be a bug in notmuch for not handling failures from the glib function correctly, in that I wasn't given any error message about the failed parse).

After more trial and error, I determined that I could work around the failures by rewriting my config file to use "[.]" instead of "\.", and then with prodding from the libera.chat #notmuch community, we then tackled finding which part of my 'dnf update' caused it.  We were able to reliable narrow it down to a 100% reproducible issue: Temporarily downgrading to glib2-2.76.1-1.fc38 lets \. work; upgrading back to glib2-2.76.5-1.fc38.x86_64 breaks it.

I'm not sure which library function in glib2 changed behaviors, but it seems like a nasty change to treat \. inside "" differently than before.  Another user claimed that 2.77.2 on Debian does not have the problem, so it may be something that upstream glib2 is already aware of, although I have not yet searched their database.

Reproducible: Always

Steps to Reproduce:
1. write an ini file containing a regex inside double quotes that wants to match a literal '.'. In my case, ~/.notmuch-config containing

[query]
foo = ( from:example.com or from:"/.*\.example\.org/" )

2. Use glib to parse the ini file, In my case, 'notmuch config list' works well.
3. 
Actual Results:  
the parse fails, and any further attempt to use config loaded from the file is doomed

Expected Results:  
the parse succeeds, with the resulting string value for the associated query.foo config item being a regex containing the two-byte sequence \.

Workaround: rewrite the affected ini files use the regex [.] instead of \. (but only helps ini files where the use of "\." was for a regex)