Importing image memory is a funny thing; there's no core mechanism
to communicate the layout of the image. Depending on how exactly
the memory was imported, and where it was imported from, it might
be possible to manage without explicit knowledge of layout, or
out-of-band mechanisms might exist to communicate it.

Today, we specifically can handle importing of memory via dma_buf
fds. While there is a Vulakn extension defined that could help
to communicate layout (VK_EXT_image_drm_format_modifier), this
extension isn't actually implemented in any driver and it doesn't
look like it will happen any time soon.

Without it, we have to hope that imported memory has the same layout
that Vulkan expects, based on the declared image format. In
practice, this has proven to be true for the real world scenario
we care about - which is importing decoded video from VAAPI - there
are only a couple of relevant formats, and the drivers for both
Vulkan and VAAPI are written by the same sets of people following
the same hardware driven recommendations for layout.

However, just because layouts match in practice, doesn't mean that
they pass validation. What we see is that, for some formats,
validation will fail when binding memory, saying that the memory
segment is smaller than the vulkan-calcuated memory size. I assume
this happens due to a difference in memory alignment (pretty much
any other cause would lead to visible errors).

As we would like to be able to use VAAPI imported surfaces without
sacrificing validation, we need a way to filter out these expected
errors, and let validation proceed as normal elsewhere.

The mechanism we've decided on is to provide a way to ignore
errors on a specified vulkan object (in our specific case, the
VkImage). We store the object ID before the bind call, and clear
it afterwards. While it is set, errors on that object will be
suppressed.

It's a simple mechanism that isn't thread safe, but could be made
so if/when the need arises.