Dma-buf feedback unnecessarily making clients use linear modifier

To include the scanout tranche in the dma-buf feedback, we check if we failed to put the fb in the plane because of the incompatibility between its DRM format/modifier and the ones supported by the KMS plane.

But there are cases in which we are more "aggressive". If drmModeAddFb2() fails, it may also be because of the fb format/modifier, see [1]. But there are other cases as well, see [2]. In this case drmModeAddFb2() fails because of how the buffer is allocated in this platform.

So this scenario exists:

• we add the scanout tranche because drmModeAddFb2() failed
• client re-allocates using a format/modifier from the scanout tranche
• Weston may continue failing to place the fb on a KMS plane
• client will end up using a sub-optimal modifier because of that

In order to avoid such cases, we could have a very simple fix:

• if the surface dma-buf feedback has scanout tranches and
• the client fb has a format/modifier present in one of the scanout tranches and
• we still failed to place it on a KMS plane,
• mark this surface to not have scanout tranches anymore, remove them from the dma-buf feedback and re-send it.

There's a downside: drmModeAddFb2() failures may be transient, as explained in [1]. So we may unfairly mark a surface to not have scanout tranches anymore, and the client may re-allocate with a format/modifier from a renderer tranche, what would cause it to never be placed in a KMS plane anymore. But maybe this downside would be better than taking the risk of ending up with clients unnecessarily using linear modifiers.

---

[1] wayland-protocols!8 (comment 1080353)

[2] https://lists.freedesktop.org/archives/mesa-dev/2024-April/226202.html