fix Metal leaking resources

[39ali]

Connections
should help fix #8018

Description
metal is leaking some strings and gpu device because metal resources hold a strong reference back to the MTLDevice

Testing
ran some custom tests that would keep creating/deleting resources

Squash or Rebase?
Squash

Checklist

• Run cargo fmt.
• Run taplo format.
• Run cargo clippy --tests. If applicable, add:
  • --target wasm32-unknown-unknown
• Run cargo xtask test to run tests.
• If this contains user-facing changes, add a CHANGELOG.md entry.

[ErichDonGubler]

@andyleiserson, could you please take this on, since you measured the original problem?

@39ali: You have merge conflicts, and need to rebase.

[andyleiserson]

Can you explain in more detail how you found this (and the similar handling for QueueShared) to be necessary? Is the idea that releasing these objects transfers ownership of some member(s) to the autorelease pool, rather than directly releasing them?

[39ali]

from my testings, it doesn't directly release them since there's no main release pool and that's because the code is not running inside Cocoa event loop so you have to manually autoreleasepool by yourself , there's probably a lot of places like this in the metal backend but this is what i currently found to be leaking

[andyleiserson]

I would prefer to omit creating autoreleasepools in Drop / destroy, unless there's compelling evidence it is necessary.

(For what it's worth, I tried running the fuzzing test case from #8018 with just the added autoreleasepools on non-destructor paths, and it did seem like the leak was resolved.)