venus: add opaque fd resource support in render server

Background:

• For guest mapping (vkMapMemory for VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT) setup, venus currenty has forced external memory on the renderer side (see this for more details).
  • With hw implementations, venus prefers VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT
    • forces dma_buf export on anv, radv and tu
    • fallback to gbm alloc + dma_buf import on mali
  • For CI testing atop lvp (sw Vulkan implementation in mesa), since lvp only supports VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT export, !651 (merged) was landed to bridge the gap. However:
    • it doesn't work for vkr behind the render server (fixed by this MR)
    • it doesn't work with sandbox enabled (to be fixed later, and not urgent before https://gitlab.khronos.org/vulkan/vulkan/-/issues/2918 gets resolved)
• For vkr in virglrenderer with/without the render server config, the high level arch
  • before this MR:
    • without server:
      • virtio-gpu device process { virglrenderer public API => vkr contexts + others (vrend and drm/msm contexts) }
        • Ps: vrend is the host side renderer for virgl stack to provide GL support in the guest
        • Ps: drm/msm is the renderer backend for freedreno's virtgpu-native-context solution (or we call it render node forwarding)
    • with server (-Drender-server=true):
      • process config (-Drender-server-worker=process):
        • virtio-gpu device process { virglrenderer public API => proxy contexts + others } =>
        • render worker processes { render context => virglrenderer public API => vkr context }
      • thread config (-Drender-server-worker=thread):
        • virtio-gpu device process { virglrenderer public API => proxy contexts + others } =>
        • render server process { render contexts => virglrenderer public API => vkr contexts }
  • after this MR:
    • without server:
      • same with above and still works, so that we can land it without disabling venus CI testing on the virglrenderer side
    • with server:
      • the thread config is preserved
      • the diff against above is replacing the virglrenderer public API with the new vkr renderer interface

Summary of the MR:

• first 7 commits are just refactors while making the threaded server config an official path instead of deprecation
  • deprecating the thread config makes the server a looooot harder to debug with..
  • now the dirty thread bits are self-contained in the render_state
• commits 8,9 implement vkr renderer interface and remove the virglrenderer middle block from the server side
• commits 10,11 update the opaque fd metadata naming and add the server support for it
• commit 12 updates naming aligned with multiple timeline
• commit 13 refactors render_state to use scoped lock

Test:

• vkr in render server atop lvp passes dEQP-VK.memory.*
• no cts regressions with crosvm and qemu
• no perf regressions with gfxbench and angle traces

Followup:

1. mandates render server config for venus
   1. uprev virglrenderer in mesa and enable render server in mesa CI
   2. uprev mesa in virglrenderer to bring in crosvm runner to enable render server in virglrenderer CI
2. further server and venus cleanup after deprecating non-server config
   1. clean up server dependencies on random virgl miscs and drop libvirglrenderer dep from server
      • Some utils used by venus can include up to virglrenderer.h. We need to clean up or have separate util.
   2. decouple vkr from virgl_resource (after iov cleanup in !943 (merged))
   3. decouple vkr from virgl_context
   4. clean up the legacy poll based fencing code paths from vkr

/cc @dawnhan @justonli