Race in output-management heads/modes

[emersion]

When plugging out an output, this sequence of events can happen (and happens in practice, see emersion/kanshi#55):

1. Compositor sends zwlr_output_head_v1.finished and destroys the object immediately. Compositor also sends a zwlr_output_manager_v1.done event with a fresh serial to apply the changes.
2. Client hasn't received the events yet. It creates a new zwlr_output_configuration_v1 with an (outdated) serial. It issues a zwlr_output_configuration_v1.enable_head request with the object that has just been destroyed by the compositor.
3. Compositor receives the request and libwayland disconnects the client with wl_display@1: error 1: invalid arguments for zwlr_output_configuration_v1@5.enable_head.

This is a race in the protocol itself. The only thing I can think of to fix it is to stop destroying immediately the zwlr_output_head_v1 objects. Instead, let the client issue a destroy request.

[any1]

Another consequence of server created objects racing with the client's object map is that when the server destroys object and creates new ones immediately after, it will send the client "new objects" with object ids that the client still has pointing to the old objects because it hasn't had a chance to remove them from its own object map when the new objects are demarshalled. Thus, the client aborts.

[emersion]

wlr-protocols has migrated to gitlab.freedesktop.org. This issue has been moved to:

https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/issues/62