gdocumentportal: Treat more error codes as a permissions error

If the file to be added is on a read-only filesystem, opening read/write
will fail with EROFS. In this case we should fall back to opening it
read-only, the same way we already do if write access is forbidden by
DAC or MAC.

An easy way to reproduce this test failure is to build and test GLib
in a podman container, with its source code read-only and its build
directory read/write:

    podman run --rm -it \
    -v $(pwd):$(pwd):ro \
    -v $(pwd)/_build:$(pwd)/_build:rw \
    -w $(pwd) ...

Before this commit, the dbus-appinfo test would fail, because opening
${srcdir}/gio/tests/org.gtk.test.dbusappinfo.flatpak.desktop read/write
would fail with EROFS.

For completeness, give similar handling to the other error codes
documented in Linux open(2) that might succeed if re-attempted using
read-only access: according to that documentation, we could get EPERM
if opening read/write is prevented by fcntl F_ADD_SEALS, or ETXTBSY
if the file is an executable that is currently being run.

Signed-off-by: Simon McVittie <smcv@collabora.com>

gio/gdocumentportal.c

@@ -101,6 +101,15 @@ opening_ro_might_succeed (int saved_errno)
     {
     case EACCES:
     case EISDIR:
+#ifdef EPERM
+    case EPERM:
+#endif
+#ifdef EROFS
+    case EROFS:
+#endif
+#ifdef ETXTBSY
+    case ETXTBSY:
+#endif
       return TRUE;
 
     default: