WIP: vulkan/wsi: Use sync files to directly signal dma-bufs
This adds a new mechanism to Vulkan WSI for transforming Vulkan's explicit sync model into the implicit sync model required by X11 and Wayland today. It does this using a new set of ioctls on dma-buf which allow you to export a sync_file from the fence on the dma-buf and allow you to signal the dma-buf using the fence in a sync_file. In order to do this, it makes two assumptions about drivers:
Drivers implement sync_file import/export for fences and semaphores.
Sync files can be exported from or imported into semaphores and fences regardless of whether they were created with SYNC_FILE among the supported handle types.
The primary advantage of the new approach is that it does even less over-synchronization than the previous approaches. Every approach we've used in the past requires that vkQueuePresent do a vkQueueSubmit so that it can signal the dma-buf implicitly as of the kernel exec call. In 778b51f4, we improved the situation a bit by only signaling the dma-buf in the vkQueueSubmit in vkQueuePresent rather than signaling on every vkQueueSubmit which touchs it (all of them if descriptor_indexing is enabled). With this new approach, we can do the minimal amount of synchronization so if the client does extra vkQueueSubmits between the final draw to the WSI image and the vkQueuePresent, we don't force the presentation engine to wait any longer than it has to.
A secondary advantage is that we can now completely separate command submission from synchronization. Assuming the driver uses syncobj or similar for implementing VkSemaphore, we no longer need to do any synchronization with dma-buf via exec calls to the kernel. Of course, the kernel may still need to do some synchronization internally for the purposes of paging and the like.