Session suspension and restoration protocol

[Roman Gilg]

As a general remark I want to expand upon, why I did work on this
protocol although Mike's xdg-session-management protocol already
existed:

The xdg-session-management protocol defines only how certain sessions
/ surfaces can be saved for later restoration and how to restore them.
But it does not define conditions on if saving is suitable at the
moment and how long the compositor needs to remember the saved
restoration info. I believe in particular the last point is crucial,
and the client needs to negotiate this with the compositor somehow
depending on what it wants to do with the restoration info.

My proposal tries to solve this by defining very tight concepts
(sleep, quit, shutdown) on what the saved surface info is intended to
be used for and allows the compositor to remove surface data, that has
not been recovered in the boundaries of these concepts.

And having DBus-Activation (or the Exec line of desktop files) defined
in the protocol as the way to restore an app after it has quit the
Wayland connection has the advantages that all information are in one
place and that client developers have it easier, since they can rest
assure that if they target this one spec and the compositor supports
the suspension level, the workspace will at some point reactivate
their app in a predictable manner.