xwayland: Drop outdated guard against clipboard races
This guard was added as part of d335070b.
The guard as-is does not work correctly. If a client quits at the wrong point or simply never responds to the request for targets, we get into a stuck state where we will never update the clipboard from Wayland to X again until the selection owner changes.
The guard appears to be outdated: The rationale given in the original MR was that it prevented a race where:
- The X11 clipboard changes
- We start fetching targets
- We notify Wayland clients that the clipboard changed is now empty
- Klipper replaces the clipboard
- Kwin then replaces the X11 clipboard
- X11 finishes fetching targets, but this is now discarded as there's a new X11 clipboard
However we can not find a path for step 2 to happen in the current codebase. Potentially due to one of many refactors over the past few years. The wayland selection is only replaced when targets are fully loaded.
The only way it could happen is if an X11 client replaced the clipboard by explicitly deleting the old selection first, but this also does not appear to happen in any tested apps.