During a drag and drop we have the source which started the drag and the target which is being dragged into.

In all the target handling codepaths we have two codepaths.

 - If we are the app that started the drag, we cut wayland out and update the drag state directly

 - Responding through wayland normally as if the drag came from another client

Doing only the latter would simplify code a lot, be generally safer and keep the compositor in the loop.

The reason we have two paths is 10 years ago the state of drag and drop on Wayland was quite bad and we wanted to make the common case of internal drags not broken. On all desktops with data_device_v3 the state is now fine. 

The part that needs most evaluation is Qt's own wayland compositor which isn't as up to date as most desktops.