backend/drm: async page flip (tearing) support for DrmSurface/DrmCompositor

[s0kil]

What

Adds async page flip (tearing) support to the DRM backend:

• DrmSurface::page_flip(planes, event, async_flip) — when async_flip is true on an atomic surface, the commit carries DRM_MODE_PAGE_FLIP_ASYNC (presented immediately, no vblank wait). Legacy surfaces currently ignore the flag (documented).
• FrameFlags::ALLOW_ASYNC_PAGE_FLIP + DrmCompositor::queue_frame_with_flags(user_data, flags) — async intent is scoped to the specific queued frame (carried in QueuedFrame, so deferred submits and interleaved plain queue_frame calls can never inherit a stale flag).
• Driver rejection (EINVAL/EBUSY) is retried once synchronously in the same submit — callers degrade to normal vsync behavior with no state divergence; first rejection is logged.

The existing queue_frame API and all default paths are behavior-identical (flag threading only, false everywhere).

Why

Compositors need this to implement wp_tearing_control_v1. Smithay currently offers no path to DRM_MODE_PAGE_FLIP_ASYNC — NONBLOCK commits are still vblank-aligned.

Validation

Consumed by a cosmic-comp branch implementing tearing-control (PR linked in comments). End-to-end on real hardware (i915 eDP scanout, kernel 7.x, DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP=1): fullscreen Vulkan client at 240fps on a 144Hz panel with visible tearing, zero rejected flips over extended play; with the feature unused, behavior is byte-identical to before (verified by review of the flag paths and by an unmodified consumer compiling and running unchanged).

Open questions (draft status)

• No capability gating yet: callers can request async on hardware without DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP; today that costs one rejected ioctl + sync retry per frame. Should DrmSurface/DrmCompositor expose the cap (and/or refuse early)?
• queue_frame_with_flags accepts full FrameFlags but only honors ALLOW_ASYNC_PAGE_FLIP — happy to reshape (dedicated parameter/type) to taste.
• Rejection outcome is not surfaced to the caller (only logged). Compositors may want accept/reject counts — worth an API?
• wp_presentation feedback still reports Kind::Vsync for async-flipped frames; fixing that properly probably belongs in this PR's scope — guidance welcome.
• Legacy KMS also supports PAGE_FLIP_ASYNC; currently ignored on the legacy path. Support or hard error?

Implementation was developed with AI assistance and human review/testing on real hardware; happy to iterate per maintainer direction.

[s0kil]

Consumer implementing wp_tearing_control_v1 on top of this: pop-os/cosmic-comp#2588 (validation details there).

[Drakulix]

I suggest cooperating on the existing approaches on implementing this feature:

• Implement wayland side of tearing control #1325
• Initial support for DRM async page flip v2 #1948

Additionally you completely ignored the PR template and the whole thing looks very AI-generated.