OBS's graphics hooks remain inside applications after OWL Control shuts down

[philpax]

• Start recording an application
• Stop recording
• Keep the application running, shut down OWL Control
• Attempt to replace OWLC\data\obs-plugins\win-capture\graphics-hook64.dll: you cannot, the file's locked
• Shut the application down
• You can now replace the DLL

My suspicion is that the module is never unloaded because we don't clean up the runtime properly. Unfortunately, we're going to have to figure that one out.

cc @Clyde013, but I'll probably need to investigate because this is threading/async heck

[philpax]

Spent a bit of time investigating this. Annoyingly, the now-100% reproduction for the deadlock is now much worse; I spent most of my time trying to get a consistent repro that I could use to determine if any fixes I made would work. Additionally, LLDB kept crashing if I inspected too many threads. I think we're just gonna have to ship without this fixed, warn people about it, and then try to fix it at some later stage.

With b4efeed, start recording, stop recording, wait some indeterminate number of minutes, and then shut down OWL Control through tray icon or Ctrl+C. If you're (un)lucky, the process will deadlock; our current understanding is that this is caused by a futures::executor::block_on that tries to lock a Tokio mutex in libobs-wrapper in the ObsRuntime's Drop within the Tokio task, leading to the thread locking up.

This is irritating and not particularly clean, but it's not a showstopper.

[exdysa]

Its back. Same expectation and step by step as before.

Launch OWL Control, record game. Reinstall. I close out OWL Control completely, then run the installer. Meanwhile, game remains open. Met with this screen.

Task manager at time of error.

it also again remedies when the game is closed, just as before.