wayland/selection: Relax wl_data_offer::finish requirements

[Drakulix]

Fixes #1875

Relevant logs:

[3737216.449] {Default Queue} wl_registry#2.global(3, "wl_data_device_manager", 3)
[3737216.451] {Default Queue}  -> wl_registry#2.bind(3, "wl_data_device_manager", 3, new id [unknown]#6)
[3737216.529] {Default Queue}  -> wl_data_device_manager#6.get_data_device(new id wl_data_device#16, wl_seat#15)
[3755269.394] {Default Queue} wl_data_device#16.selection(nil)
[3757597.275] {Default Queue} wl_data_device#16.data_offer(new id wl_data_offer#4278190080)
[3757597.302] {Default Queue} wl_data_offer#4278190080.offer("text/x-moz-url")
[3757597.310] {Default Queue} wl_data_offer#4278190080.offer("_NETSCAPE_URL")
[3757597.312] {Default Queue} wl_data_offer#4278190080.offer("text/x-moz-url-data")
[3757597.315] {Default Queue} wl_data_offer#4278190080.offer("text/x-moz-url-desc")
[3757597.316] {Default Queue} wl_data_offer#4278190080.offer("application/x-moz-custom-clipdata")
[3757597.319] {Default Queue} wl_data_offer#4278190080.offer("text/_moz_htmlcontext")
[3757597.320] {Default Queue} wl_data_offer#4278190080.offer("text/_moz_htmlinfo")
[3757597.322] {Default Queue} wl_data_offer#4278190080.offer("text/html")
[3757597.324] {Default Queue} wl_data_offer#4278190080.offer("text/plain")
[3757597.326] {Default Queue} wl_data_offer#4278190080.offer("text/plain;charset=utf-8")
[3757597.327] {Default Queue} wl_data_offer#4278190080.offer("UTF8_STRING")
[3757597.329] {Default Queue} wl_data_offer#4278190080.offer("STRING")
[3757597.358] {Default Queue} wl_data_offer#4278190080.offer("DELETE")
[3757597.359] {Default Queue} wl_data_offer#4278190080.source_actions(3)
[3757597.362] {Default Queue} wl_data_device#16.enter(3114, wl_surface#29, 761.49609375, 84.65625000, wl_data_offer#4278190080)
[3757597.522] {Default Queue}  -> wl_data_offer#4278190080.receive("text/x-moz-url", fd 50)
[3757598.061] {Default Queue}  -> wl_data_offer#4278190080.set_actions(3, 1)
[3757606.997] {Default Queue}  -> wl_data_offer#4278190080.accept(3114, "text/uri-list")
[3757607.002] {Default Queue} wl_data_device#16.motion(16296142, 757.49609375, 88.65625000)
[3757607.052] {Default Queue}  -> wl_data_offer#4278190080.set_actions(3, 1)
[3757607.097] {Default Queue}  -> wl_data_offer#4278190080.accept(3114, "text/uri-list")
[3757607.099] {Default Queue} wl_data_device#16.motion(16296143, 755.49609375, 90.656250
[... repeating motion + accept(3114, "text/uri-list") events]
[3758007.384] {Default Queue} wl_data_device#16.drop()
[3758007.782] {Default Queue}  -> wl_data_offer#4278190080.finish()
[3758007.789] {Default Queue} wl_data_device#16.leave()
[3758007.795] {Default Queue}  -> wl_data_offer#4278190080.destroy()

Dolphin will first immediately receive the contents for the mime-type "text/x-moz-url", which is advertised and valid, but then try to issue an accept for "text/uri-list", which firefox never advertised.

The protocol doesn't really specify what to do in this case and since smithay tests for the mime-type, it marks the offer as accepted = false;. Alternatively we could error out here earlier and just send some protocol error(?) but this isn't a defined error case.

I think marking it as "not accepted" however is correct, because that leads to the source receiving a cancel-event on drop and no "successful" transfer for the wrong mime-type happening, but wl_data_offer::finish only has the following error cases:

It is a client error to perform other requests than wl_data_offer.destroy after this one. It is also an error to perform this request after a NULL mime type has been set in wl_data_offer.accept or no action was received through wl_data_offer.action.

Dolphin never send a NULL-mime-type nor empty actions. So we should probably just ignore the finish request in this case? That is what this PR does, relax the requirements, so we don't protocol error on this rather harmless request.

Interestingly the drop "succeeds" from a UX perspective and Dolphin just uses the data it previously already received for the correct mime-type... To be very clear, I still think this is a client error, that should be fixed upstream, but I also don't think relaxing it this way does any harm.

[Naxdy]

Just tested using anvil in this branch, and can confirm that DnD of hyperlinks from Firefox -> Dolphin now works properly.

[PolyMeilex]

I agree that this is kinda fishy behavior on the client's side, but I also don't see the harm in relaxing those checks.

[LuckShiba]

Noting here that this PR also seemingly fixed a issue where Telegram Desktop app would crash when links were dragged to it

Maybe a QT issue instead of Dolphin alone?