Missing synchronization validation for XFB counter resume

Describe the situation in which you encountered the missing validation

When using XFB, we can temporarily deactivate it with vkCmdEndTransformFeedbackEXT and later resume it with a new call to vkCmdBeginTransformFeedbackEXT using the same counter buffer. This is described in the spec in multple places, like in vkCmdEndTransformFeedbackEXT:

The counter buffers are used to record the current byte positions of each transform feedback buffer where the next vertex output data would be captured. This can be used by a subsequent vkCmdBeginTransformFeedbackEXT call to resume transform feedback capture from this position. It can also be used by vkCmdDrawIndirectByteCountEXT to determine the vertex count of the draw call.

However, to do that we need a barrier to synchronize counter writes with counter reads, as explained in the extension Q&A section:

RESOLVED: Yes, this is needed to ease layering other APIs which have this functionality. To pause use vkCmdEndTransformFeedbackEXT and provide valid buffer handles in the pCounterBuffers array and offsets in the pCounterBufferOffsets array for the implementation to save the resume points. Then to resume use vkCmdBeginTransformFeedbackEXT with the previous pCounterBuffers and pCounterBufferOffsets values. Between the pause and resume there needs to be a memory barrier for the counter buffers with a source access of VK_ACCESS_TRANSFORM_FEEDBACK_COUNTER_WRITE_BIT_EXT at pipeline stage VK_PIPELINE_STAGE_TRANSFORM_FEEDBACK_BIT_EXT to a destination access of VK_ACCESS_TRANSFORM_FEEDBACK_COUNTER_READ_BIT_EXT at pipeline stage VK_PIPELINE_STAGE_TRANSFORM_FEEDBACK_BIT_EXT.

The layers currently lack this synchronization validation.

One easy way to test this are the upcoming CTS tests for xfb outputs with degenerate triangles and primitive restart. See internal Khronos CTS issue number 5558 and the resumeBarrier used there.

Valid Usage IDs requested
N/A

Additional Context
N/A