Check our handling of buffer destroy semantics.

[elinorbgr]

According to folks on #wayland, it is valid for a client to destroy a buffer right after having commited it (and thus before receiving a release event). The compositor should still be able to set the surface content accordingly.

When doing so, a client simply promises that it'll never modify the underlying storage for the buffer ever again. Some clients use that to set surface contents in a one-shot way (for example swaybg does this).

We should check that our current implementation (in particular all the transaction and state caching logic) does correctly respect that, and if not, fix it.

[Drakulix]

For what it is worth: swaybg works fine with smithay today, so we probably do handle this correctly. I agree though we should make sure and potentially add some comments.

[i509VCB]

Doesn't wl-shm have a stricter requirement than mentioned in #wayland?

[elinorbgr]

Stricter how so?