WL_SURFACE_ID is racy

1. Xwayland sends a wl_compositor.create_surface request to the Wayland compositor in ensure_surface_for_window. The surface gets assigned object ID 42.
2. Xwayland sends a WL_SURFACE_ID client message to the compositor's XWM with data[0] = 42.
3. xwl_unrealize_window is called quickly after. Xwayland sends a wl_surface@42.destroy request.
4. Xwayland sends a destroy notify message for the X11 window to the compositor's XWM.
5. Xwayland creates a completely different Wayland object (e.g. another wl_surface or even a different interface), and ID 42 gets re-used. Wayland object IDs get re-used pretty aggressively.

The issue is that delivery of Wayland events and X11 events is unordered. The compositor might process all Wayland events at once, then do something else, then process the X11 events. Or the other way around: process the all of the X11 events first, then all of the Wayland events. This might confuse the compositor, as it might mis-associate a X11 window and a Wayland object.

We had a crash in our compositor because the compositor was getting a WL_SURFACE_ID which turned out to refer to a wl_shm_pool object.

Because the X11 window and the wl_surface are created and destroyed together, the potential for badness probably isn't too high. If a mis-association happens, the X11 window should get destroyed shortly after. But I figured it's a good idea to keep this race in mind when implementing the WL_SURFACE_ID logic in a compositor, at least to be prepared for the object ID to refer to something that isn't a wl_surface.

If we wanted to fix the race, some kind of serial mechanism and/or a Wayland protocol could probably help.