Wayland backend questions/notes/issues

Nobody has claimed this yet.

Hi! I've been trying to use druid for my Wayland related project, but have encountered some unusual things in the wayland implementation.

## Rendering
It's better to just show it instead of describing it, so here is the video of window resizing, it looks like there is something wrong in double buffering implementation, or perhaps xdg configure is somehow handled against the spec:

[druid-rendering.webm](https://user-images.githubusercontent.com/20758186/188284487-4bef8354-c133-4006-a4f6-ab34ac3aea83.webm)

## Handling of protocol versions
Addressed by: https://github.com/linebender/druid/pull/2254
~~The choice of versions seems completely random and not based on any requirements, lack of certain version is not handled either.~~

#### ~~Examples~~
- ~~Druid does not run on Weston (reference implementation of wayland) because it tries to bind `xdg_wm_base` version 2, version 2 of xdg-shell introduced `tiled_top/left/right/bottom` states, but druid does not use them at all as far as I can tell, so why does it require it?~~
- ~~Druid does not work on Mutter (Gnome's compositor) because it ignores any `wl_seat` versions lower than 7 also for no apparent reason (my memory is rusty but as far as I remember version 7 was mostly server side change that adds extra requirement for clients to map keymap file with MAP_PRIVATE, so I'm not sure why druid cares enough to straight up refuse to run on older versions)~~

#### ~~Potential solution~~
~~Either we bind the lowest possible and carefully chooses version, or we have to handle multiple versions properly.
For example In [sctk](https://github.com/Smithay/client-toolkit) we simply define latest supported version and bind whatever meets `1..=max_version` requirement. After that, any calls to newer methods are guarded by `obj.version() >= n`~~

~~## Handling of non-core protocols
I'm pretty sure that this is fixed by #2127, but I'll describe it anyway.
Druid does not run on Weston and Mutter because it tires to bind optional protocols like `xdg decoration` and `layer shell`, (layer shell is still in the process of standardization in Wayland).
It's cool to use non-core protocols, or event protocols not standardized in Wayland like layer shell, but all usage of those has to be behind `Option` we can't just assume that it is available everywhere.~~

---

### Side question: Why not Smithay client toolkit?
While reading the code, I see a lot of reinventing the wheel, most of the stuff that is not implemented, partially implemented or broken in druid is available in Smithay client toolkit and was since the early beginnings of wayland-rs. Was it considered? If so, what was the deciding factor to not use it, is there anything I can do to make it more suitable? It was designed to be modular and not take control away from the user, so I was pretty sure that druid will use it, the same way winit does, so I was surprised to find out that it does not. Would love to hear some feedback.

Start by checking the rendering video and the current Wayland backend; the protocol-version and optional-protocol sections are marked addressed by PRs #2254 and #2127. Confirm whether the resizing artifact still reproduces, then document a focused fix or follow-up with a concrete completion condition.

Written by the indexing model from the issue text.