Merge #1240

1240: Fix issue with multiple queued mappings where the last one is not cancelled r=kvark a=Imberflur


**Connections**
Follow up from #1239

**Description**
In #1239 I missed the case where there are multiple rounds of mapping/unmapping with the last map not being cancelled. In practice it doesn't occur very often, but I did encounter it with settings/a scene that created a heavy GPU load.

Sorry for not catching this earlier!

**Testing**
Using `wgpu-rs` capture example, after the first `map_async` I added in an `unmap` followed by another `map_async`.
<!--
Non-trivial functional changes would need to be tested through:
  - [wgpu-rs](https://github.com/gfx-rs/wgpu-rs) - test the examples.
  - [wgpu-native](https://github.com/gfx-rs/wgpu-native/) - check the generated C header for sanity.

Ideally, a PR needs to link to the draft PRs in these projects with relevant modifications.
See https://github.com/gfx-rs/wgpu/pull/666 for an example.
If you can add a unit/integration test here in `wgpu`, that would be best.
-->


Co-authored-by: Imbris <imbrisf@gmail.com>

wgpu-core/src/device/life.rs

@@ -700,6 +700,12 @@ impl<B: GfxBackend> LifetimeTracker<B> {
                     resource::BufferMapState::Waiting(pending_mapping) => pending_mapping,
                     // Mapping cancelled
                     resource::BufferMapState::Idle => continue,
+                    // Mapping queued at least twice by map -> unmap -> map
+                    // and was already successfully mapped below
+                    active @ resource::BufferMapState::Active { .. } => {
+                        buffer.map_state = active;
+                        continue;
+                    }
                     _ => panic!("No pending mapping."),
                 };
                 let status = if mapping.range.start != mapping.range.end {