Vulkan: Fix unhandled deferred clears after glGetMultisamplefv Issue was introduced in the commit that implemented deferred clears. The `glGetMultisamplefv()` synchronizes draw framebuffer which defers possibly staged clears. Since API is not handling deferred clears they are left untouched, causing the ASSERT. This change fixes the issue by not deferring clears for the `glGetMultisamplefv()` command during flushing staged updates of dirty framebuffer attachments. Changes: - Add `gl::Command::GetMultisample` enumeration for clarity. - Add `gl::CommandBlitBuffer::CommandBlitBufferDepthStencil` enumeration to improve code readability. - Add `command` parameter into `gl::State::syncDirtyObject()` method to use actual command enum instead of `Other`. - Remove `previousDeferredClears` local variable and update ASSERT in the `FramebufferVk::syncState()` method. New assert ensures empty `mDeferredClears` instead of just checking dirty attachments, since it is easy to make all attachments dirty making old and new assertions act the same. - Replace logic in `FramebufferVk::syncState()` that decides whether need to defer attachments or not with switch-case. This makes the logic more clear regarding handling individual commands and simplify updating this handling in the future. Except of the bug fix with `GetMultisample` command, handling of other command is uncached. - Remove `flushDeferredClears()` from `FramebufferVk::readPixels()` because `mDeferredClears` are not expected (now it's more clear after the refactoring). And even if there are `mDeferredClears` (in case of a bug or after API failure), `flushDeferredClears()` only flushes clears for the draw framebuffer, while checking `mDeferredClears` of the read framebuffer. This is a problem in case if read and draw framebuffers are not the same. Bug: angleproject:40644727 Test: angle_end2end_tests --gtest_filter=TextureMultisampleTest.GetMultisamplefvAfterClear/* Test: angle_end2end_tests --gtest_filter=EGLSurfaceTest.GetMultisamplefvAfterClear/* Change-Id: I376a62de52de5e17dbc63cc7ddb0506741a69266 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6661958 Commit-Queue: Igor Nazarov <i.nazarov@samsung.com> Reviewed-by: Charlie Lao <cclao@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>