xdg-toplevel-drag: origin surface should probably be retained at compositor side

Drag-and-drop protocol does not explicitly say that a session should be cancelled if/when the origin surface gets destroyed, though that's what most compositors currently do (and it makes sense).

Though, for toplevel-drag capable dnd sessions, it's a common requirement that the session keeps alive when, for example, a browser toplevel (where the drag started) is dragged into (docked, ie: destroyed) another browser window. That's the case for Chromium's tab drag for example which, to accomplish it, retains the origin wl_surface at client-side.

So, questions here are:

• Should the xdg-toplevel-drag protocol be more explicit about this and keep the responsibility of handling that at client side?
• Should it be shifted to the compositor? ie: the compositor retains the origin surface when there's a toplevel-drag object attached?