Draft: Fix VUID-VkSwapchainCreateInfoKHR-presentMode-02839

[r-potter]

Including a VkSurfacePresentModeEXT in the call to GetSurfaceCapabilities makes this check more strict than it should be.

This will require WG discussion. Internal Khronos spec issue to follow

This PR: #6351 was introduced to handle a case where chaining a VkSurfacePresentModeEXT lowered the minImageCount. However, we have also observed cases were it instead increases it, which causes validation errors in the opposite direction.

This PR makes validation layers actually check what VUID-VkSwapchainCreateInfoKHR-presentMode-02839 says the rule is (i.e. the value returned by the unextended function). Unfortunately this will go back to throwing errors in the case that triggered #6351. The spec has this note describing this functionality, but no VUs corresponding to it, and so its unclear both how to validate this, and how to correctly use the functionality:

If VkSwapchainPresentModesCreateInfoEXT is provided to swapchain creation, the requirements for forward progress may be less strict. For example, a FIFO swapchain might only require 2 images to guarantee forward progress, but a MAILBOX one might require 4. Without the per-present image counts, such an implementation would have to return 4 in VkSurfaceCapabilitiesKHR::minImageCount, which pessimizes FIFO. Conversely, an implementation may return a low number for minImageCount, but internally bump the image count when application queries vkGetSwapchainImagesKHR, which can surprise applications, and is not discoverable until swapchain creation. Using VkSurfacePresentModeEXT and VkSwapchainPresentModesCreateInfoEXT together effectively removes this problem.
VkSwapchainPresentModesCreateInfoEXT is required for the specification to be backwards compatible with applications that do not know about, or make use of this feature.

[ci-tester-lunarg]

CI Vulkan-ValidationLayers build queued with queue ID 223790.

[ci-tester-lunarg]

CI Vulkan-ValidationLayers build # 17118 running.

[ci-tester-lunarg]

CI Vulkan-ValidationLayers build # 17118 passed.

[artem-lunarg]

@r-potter #8794 PR handles both the original use case from #6351 and also the situation you mentioned above (we had similar errors on our Android CI).