app: don't propagate resize requests from statusbar to display shell.

See discussion in !572, #7840 and #7690. Note that this was reported on
macOS where the consequences were pretty dire, but it actually also
happens on other platforms, at least on Linux too (as confirmed in X11
with the GTK Inspector set to show graphics updates; on Wayland this
debug option doesn't work, but I assume it is the same).

I am not perfectly happy with this change either, because it is based on
part of the API which has various deprecated parts (hence doesn't exist
anymore on the main dev tree, i.e. it might have to be reviewed in GTK4;
of course, it's unsure, maybe the whole resize propagation to parent
containers is just better handled there and the problem won't exist
anymore).
In any case, it is cleaner than the proposition for this part of the
problem in !572 which is problematic (patching GtkLabel with a new API
which won't trigger resize even when actually needed, hence which likely
won't ever get accepted upstream because it's not right).

app/display/gimpstatusbar.c

@@ -203,6 +203,31 @@ gimp_statusbar_init (GimpStatusbar *statusbar)
   gtk_container_add (GTK_CONTAINER (statusbar), hbox);
   gtk_widget_show (hbox);
 
+  /* When changing the text of the cursor_label, it requests a resize
+   * bubbling up to containers, up to the display shell. If the resizing
+   * actually happens (even when the size is the same), a full "draw"
+   * signal is triggered on the whole canvas, which is not a good thing
+   * as a general rule (and very bad on some platforms such as macOS).
+   * It's too late to do anything when processing the "draw" signal
+   * because then we can't know if some part of the invalidated
+   * rectangle really needs to be redrawn. What we do is not propagate
+   * the size request back to container parents. Instead we queue the
+   * resize directly on the widget.
+   *
+   * Note that the "resize-mode" property seems to be unrecommended now
+   * (though only the public functions are deprecated, we get no
+   * deprecation setting as a property) but it's still here in GTK3 and
+   * still seems like the proper way to avoid propagating useless
+   * no-actual-size-change resizes to container widgets.
+   * XXX On GTK4, we will likely have to test again and if it's still a
+   * problem, make a different fix.
+   *
+   * See discussion in MR !572.
+   */
+  g_object_set (statusbar,
+                "resize-mode", GTK_RESIZE_QUEUE,
+                NULL);
+
   statusbar->shell          = NULL;
   statusbar->messages       = NULL;
   statusbar->context_ids    = g_hash_table_new_full (g_str_hash, g_str_equal,