All globals should have a destroy event

[emersion]

Globals are destroyed with the display. However, if the compositor sets up a listener for a global (e.g. new_surface on wlr_compositor) it needs to remove the listener before the global is destroyed. It can't use the display destroy event since there's no ordering guarantee.

Thanks @martinetd for bringing this up in #1092 (comment)

[emersion]

We also need to decide what to do when the compositor wants to destroy the global.

• We currently destroy all associated resources. This effectively cleans up everything, but will disconnect clients that try to use the destroyed resources afterwards.
• We could make resources inert instead, but that requires to accommodate all interfaces to support inert resources.
• We shouldn't destroy the global while letting the resources alive and non-inert. This would just be asking for trouble.
• We could remove the destroy function, and keep destroying the global when the display is. In this case, I think keeping destroying resources like we currently do is fine.

[Ongy]

We shouldn't destroy the global while letting the resources alive and non-inert. This would just be asking for trouble.

Some protocols (e.g. tablet-v2) require something like this.
The actual global should become inert, but everything created from the global is explicitly not destroyed after the global got removed.

[emersion]

Fixed by #1200

[emersion]

Some protocols (e.g. tablet-v2) require something like this.
The actual global should become inert, but everything created from the global is explicitly not destroyed after the global got removed.

When I say "destroy the global", I refer to the wl_global on the compositor side, not a specific client's global.