Ensure that DeviceLostCallbackC is always called exactly once

[bradwerth]

Connections
N/A

Description
The DeviceLostClosure callback should guarantee that the closure is eventually called exactly once. The changes here ensure that the callback is called when the DeviceLostClosureC or DeviceLostClosureRust is dropped, only if it hasn't already been called.

Testing
The Rust embedding is checked in a new test DEVICE_DROP_THEN_LOST.

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.
• Add change to CHANGELOG.md. See simple instructions inside file.

[nical]

For the map callback we had to be make sure to always invoke the callback explicitly when we know for sure that wgpu is not holding any locks, and panic in the drop implementation instead of firing the callback if it was not call already.

I suspect that we need to do the same thing for the device lost callback. It may be a bit less risky to just fire the callback since the user is unlikely to use the API after the device is lost and cause deadlocks, although it could drop some resources which would likely cause the same issues.

[bradwerth]

For the map callback we had to be make sure to always invoke the callback explicitly when we know for sure that wgpu is not holding any locks, and panic in the drop implementation instead of firing the callback if it was not call already.

No-invocation-then-drop seems like it would be the most common case, though. The pattern { let device = adapter.requestDevice(...); } would trigger it, right? It seems we can't treat that as a panic condition, no matter what else we do.

I'll keep thinking about how a C-style embedding user agent can manage the callback parameter memory, fulfilling the requirements:

1. wgpu may call the callback at any time
2. wgpu may never call the callback

[nical]

Sorry my explanation was a bit confusing. I meant that wgpu is responsible for calling the callback explicitly for example in device drop, and make certain that it does so when no internal lock is held.

So DeviceLostClosure::drop would panic if the closure has not been fired (to help catch our mistakes), and other key places like device_drop or device_maintain would invoke the callback wherever it makes sense as long as no internal wgpu lock is being held.

wgpu may never call the callback

No I think that requiring wgpu to call the callback is the right thing to do, we should just ensure that it doesn't do it while holding a lock, because the callback might cause us to call into wgpu and deadlock if some lock was already held.

[bradwerth]

Okay, I'll clean this up and get serious about landing it. If wgpu is going to pledge to call this callback at least once before the device is dropped, I can build code that does that safely regarding the locks.