Make sure to unset current context in wgl Surface::configure/present

[Imberflur]

Connections
None known

Description
When re-building pipelines in background threads on the wgl backend we encounted this panic:

called `Result::unwrap()` on an `Err` value: Os { code: 170, kind: ResourceBusy, message: "The requested resource is in use." }

which is produced by the unwrap when making a context current fails here

wgpu/wgpu-hal/src/gles/wgl.rs

Line 76 in 7774f31

inner.context.make_current(inner.device.dc).unwrap();

I tracked this down to Surface::configure and Surface::present not unsetting the current context after setting it even though they release the associated lock used for synchronizing this.

To fix this I took advantage of the existing guard type and added a new locking + make current method (called lock_with_dc that allows passing in the DC that Surface::configure/Surface::present were previously passing directly to make_current.

Note that with this guard type, if unmake_current fails it will panic. I wasn't completely sure if this was appropriate for Surface::configure/present since they return errors instead of panicking when make_current fails. However, if unmake_current fails it seems like later calls to make_current (if called on a different thread) would also fail causing AdapterContext::lock to panic anyway? I'm not really familiar with what would cause unmake_current to fail though and what the behavior would be in terms of whether make_current can succeed later after such a failure.

Note, another small behavior change is that this uses the same .try_lock_for(Duration::from_secs(CONTEXT_LOCK_TIMEOUT_SECS)) pattern instead of just a .lock().

Testing
To reproduce this I spawned an extra thread in the examples framework.rs that called Adapter::get_texture_format_features in a loop. This consistently produced panics when trying to make the gl context current to that thread. After this change, no panics were observed with this testing setup. Additionally, the original issue when re-building pipelines seems to be resolved.

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.

[cwfitzgerald]

Very nice!