Implement i3 sync protocol

[RedSoxFan]

Related to #3082

UPDATE: It has been decided that sway will not support the i3 sync protocol. This just returns {'success': false} when receiving and IPC_SYNC request.

**PREFACE** I am not too familiar with x11 terminology so sorry if there are any incorrectly used terms.

SUMMARY
Implements the i3 sync protocol introduced in i3 4.16. This includes two
parts: I3_SYNC and IPC_SYNC.

The protocol ensures that all pending operations for a window have
completed. It was designed for i3 tests, but can be used by other
applications. However since this uses x11 events, it will only be
available in sway for xwayland applications.

DETAILS
To request a sync with i3, the client window will send a client message
with the type of the atom by the name of I3_SYNC. The client message
will have two data values, both 32-bit integers, the first being the
window id of the client and the second a random number. When sway
receives the event, it will send a client message to the window id
specified with the same data values. As a safety measure (and to aid in
testing), if the client message window id matches the window data value,
no reply will be sent to prevent starting a cycle.

Likewise, the IPC_SYNC (command 11) message should have two integer keys
window and rnd. If the message is not valid JSON, one of the keys is
missing, or if sway is compiled without xwayland support, the reply is
{"success": false}. Otherwise, an I3_SYNC request is sent to the
window with the id specified by window with the random specified by
rnd and the reply is {"success": true}.

For both cases, the I3_SYNC request may be queued. Since the purpose of
the sync is to make sure all operations have occurred, if the window id
is a view, the reply will queued as part of a transaction. When the
transaction is applied, the I3_SYNC request will be sent. If the window
id is not associated with any view, the I3_SYNC request will be sent
immediately since there is no node associated with the sync request.

In i3, it appears that IPC_SYNC is used to sync i3 and i3bar and I3_SYNC
used to sync i3 with client windows. Sending I3_SYNC to i3bar, results in
i3bar sending IPC_SYNC to i3, which then sends I3_SYNC to the client
window. Since swaybar does not use xwayland, this will not be possible
in sway, but both are implemented for any xwayland clients that want to
use it.

To aid in testing this, support for sending IPC_SYNC commands was added
to swaymsg. Example: swaymsg -t sync "{'window': 26215, 'rnd': 857}"

TESTS (feel free to change any rnd values, they are just examples)

1. Receiving IPC_SYNC
   • swaymsg -t sync "{'window': 262153, 'rnd': 823}"
   • Grepping the sway debug log for IPC_SYNC should yield IPC_SYNC received 823 from 0x0040009
2. Sending I3_SYNC (queued -- view)
   • Run x11trace urxvt in a terminal
   • In the opened urxvt window, run xdotool getactivewindow
   • In another terminal, run swaymsg -t sync "{'window': <id outputted from xdotool>, 'rnd': 489}"
   • The x11trace output should list a client message with the data
     containing the window and rnd values
   • If you grep the sway log, it should also show the sync request was
     queued and then send as part of a transaction
3. Sending I3_SYNC (immediate -- unmanaged)
   • Make sure there are no xwayland views or unmanaged surfaces
   • Run x11trace rofi -show run in a native wayland terminal
   • In a second wayland terminal, run xwininfo -root -tree
   • Note the window id for rofi and convert it to decimal
   • Run swaymsg -t "{'window': <rofi id>, 'rnd': 3458}"
   • The x11trace output should list a client message with the data
     containing the window and rnd values (output for rofi moves fast
     so either watching carefully or grepping will be required)
   • If you grep the sway log, it should also show the sync request was
     sent immediately since the window id was not a view.
4. Receiving I3_SYNC
   • Run xwininfo -root -tree
   • Note the window id for wlroots wm and convert it to decimal
   • Run swaymsg -t sync "{'window': <wlroots wm id>, 'rnd': 936}"
   • Grepping the sway debug log for I3_SYNC should yield I3_SYNC received 936 from <wrloots wm id as hex>

[emersion]

Do we have a use-case for this? On Wayland, clients can send wl_display.sync to do a roundtrip.

[RedSoxFan]

Do we have a use-case for this? On Wayland, clients can send wl_display.sync to do a roundtrip.

I'm not really sure. In i3, it was added for their testing suite. I doubt there are many (if any) client window that implement or would implement syncing with a specific window manager/compositor. This PR is mainly for compatibility if any client were to actually implement it. If you want, a wayland equivalent can be added

[emersion]

This PR is mainly for compatibility if any client were to actually implement it.

Not sure it makes sense for us to have this feature,

If you want, a wayland equivalent can be added

No need for this, it's already baked in the Wayland protocol itself (wl_display.sync).

[RedSoxFan]

I can change this to just be a minimal {'success': false} on IPC_SYNC and #3082 can be closed (since this is the last item), if you would prefer

[emersion]

OTOH, maybe it could be useful to run the i3 test suite on Sway?

[RedSoxFan]

Honestly, I have no idea how useful this PR is. I do think sway should handle IPC_SYNC, but whether or not it implements the protocol or just returns a failure seems borderline. I tried to make this PR as encapsulated in the xwayland file as possible.

[ddevault]

I think this is basically an internal i3 feature that we should just return success: false on.

[emersion]

Thanks!