[capture] "WARNING - Failed to map handle for object id" when swapchain recreated before capture starts

[w-pearson]

Describe the capture bug:
If the swapchain is recreated before a trimmed capture is started, then the oldSwapchain value will point to a nonexistent handle. During replay, this will result in a "WARNING - Failed to map handle for object id" message, and the handle will be set to VK_NULL_HANDLE.

I'm pretty sure there are no ill effects from this, and it is always legal to set oldSwapchain to VK_NULL_HANDLE, but the capture containing an invalid handle is still somewhat odd, and this creates minor problems for analysis (mainly due to the missing handle).

This is somewhat exacerbated on Android where some apps recreate the swapchain every frame (see SaschaWillems/Vulkan#1150).

Note that if the oldSwapchain from the first swapchain used in the capture were recorded, it would still be necessary to record that swapchain's oldSwapchain, all the way back to the start of the app, which may be a lot of swapchains if they end up getting recreated frequently. I don't know if there's any use-case for that.

Build Environment:
Version used by Vulkan SDK 1.3.280.0.

Capture Settings:
No special settings needed, other than creating a trimmed capture (I used a hotkey).

To Reproduce:

• Configure GFXR to make trimmed captures.
• Launch e.g. the Sascha Willems Pipelines sample.
• Resize the window.
• Start and then stop capture.
• Attempt to replay the capture.
• Observe that "WARNING - Failed to map handle for object id" is logged.

System environment:

• Windows 10
• NVIDIA GeForce RTX 4070 Laptop GPU
• Driver version 537.34.0.0

[panos-lunarg]

Retaining the swapchain object wrappers so that the state writer will also dump the creation of the deleted swapchains is not that straight forward because when there are multiple swapchains are created and destroyed consecutively (for example when dragging the mouse to resize a window) the CreateSwapchain following a DestroySwapchain is very likely to return the same handle. This creates a conflict in the internal map that holds the Vulkan handles <-> wrapped vulkan objects.
Will try to find a work around

[bradgrantham-lunarg]

@mikes-lunarg is working on a swapchain fix. @mikes-lunarg is this related?