Add check to ensure vulkan::CommandEncoder::discard_encoding is not called multiple times in a row

[villuna]

Connections
Addresses #5255

Description
I just followed the (very helpful) todo list in Erich's issue, so the info is mostly there.

The vulkan implementation for CommandEncoder was previously pushing its active CommandBuffer handle to its discard vector every time the discard_encoding function was called, even if the handle was null. So I made it only do this if the active handle is non-null, so as to make the function idempotent.

Testing
No new tests but I ran the existing test suite on Vulkan (on an Nvidia GTX1050) and it ran the same as on the trunk branch.

Checklist

• Run cargo fmt.
• Run cargo clippy. If applicable, add:
  • --target wasm32-unknown-unknown
  • --target wasm32-unknown-emscripten
• Run cargo xtask test to run tests - I got one error every now and then, but this also happened on the main branch so I think it's fine.
• Add change to CHANGELOG.md. See simple instructions inside file.

[cwfitzgerald]

Looks good, going to flag Erich on this one

[jimblandy]

I'm actually -0.5 on this PR. The idea is for wgpu_hal traits to permit implementations to track as little state as pratical, and put all state tracking, validation, resource management, etc. in common code in wgpu-hal. Properties like idempotence should be easily manageable in wgpu-core.

[jimblandy]

Having thought about this more, I'd like to put a temporary pause on this PR.

At least given my understanding of the role wgpu's core/hal distinction is supposed to play in keeping wgpu maintainable, adding obligations that wgpu-hal trait implementors must meet to make life easier for their users is putting the code in the wrong place. State tracking, validation, and resource management should be handled in common code within wgpu-core, not repeated in each wgpu_hal backend.

@villuna, apologies for the back-and-forth - there's nothing wrong with the code at all, and it looks like it correctly implements the intended change. I just want a day or so for the maintainers to talk things over and get a shared understanding.

[jimblandy]

For what it's worth, I've been looking into wgpu-core's handling of hal command encoders over the last week, in the process of trying to get a handle on our locking/synchronization story (see #5539, for example). I'd started to put together some ideas on how to clarify the life cycle of command encoders in core, and make it "correct by construction" that the wgpu_hal::CommandEncoder contract is satisfied. Clearly I'm not the only person with this on their mind!

[jimblandy]

It sounds like we've got some consensus around #5566, so in that context:

[villuna]

Thanks for the comments, I've made the changes you requested. I've also removed the drop implementation, since it was calling discard_encoding twice and triggering the assert panic 😅. I guess it's working

[jimblandy]

Looks good to me. I did some minor copy-editing.

Superseded by subsequent reviews.