xdg-decoration: No object vs set_mode client-side

This issue is to discuss what the exact differences are between a client that does not create a xdg_toplevel_decoration object, vs one that does but calls set_mode(client-side). This is mostly because I've seen a lot of confusion around the protocol and what what exactly clients should do.

For the sake of clarity I think it's worth mentioning all the the following:

1. Without a decoration object the client assumes CSD.
2. A compositor may still have to decorate a client without a xdg_toplevel_decoration object.
3. Clients must not draw decorations if the client receives SSD.
4. Clients don't have to draw decorations if the mode is CSD, nor do compositors if the mode is SSD. The configured mode is simply who is responsible for them.
5. Destroying the decoration object reverts to CSD, however because of point 2 the client can't force the compositor to remove its own decorations by doing so.
6. Clients cannot create a xdg_toplevel_decoration object for an already mapped toplevel. This is supposedly a problem and the subject of !17.
7. xdg-decoration is purely for the compositor's benefit, not the clients. Clients always have to support CSD, be it configure(client-side) or no decoration object.

GNOME authors assert that they do not need to implement xdg-decoration, because mutter would always do configure(client-side), and thus set_mode is a noop. This would mean that they view the behavior as identical to no object at all.

A toolkit, like Qt use FramelessWindowHint, which "Produces a borderless window.", but since clients set this if they want to draw their own decorations its technically CSD, not no decorations. Also Qt simply isn't equipped to handle the compositor enforcing a different mode and therefore destroys the decoration object to try a force CSD, Again see !17. This means Qt sees no object and set_mode(client-side) differently.

The same goes for Sway. @emersion correct me if I'm wrong but I think it was you who used the phrase "more explicit action" to distinguish between set_mode(client-side) and no object. If so then it's clear that Sway treats them differently.

I think the big question is what is a compositor supposed to do differently between set_mode(client-side) and no object? A "more explicit action" is vague and completely meaningless on its own.

I think that because of point 2 the solution is to treat no object and set_mode(client-side) the exact same way, it greatly simplifies the protocol, removes any confusion, and prevents clients from doing stupid things like destroying the decoration object.

To work around point 2 !200 (closed) can be merged. See !200 (comment 2001014)