unawaited async lock guards

use tokio::sync::Mutex;

static LOCK: Mutex<()> = Mutex::const_new(());

async fn foo() {
    let _guard = LOCK.lock();
    // do some work with the lock held
}

It looks like foo is taking a static async Mutex, but it's not actually locking anything, because it doesn't .await the call to LOCK.lock(). You get a type error here if the lock contains a value that you're actually trying to use, but when you're just taking a lock for its side effects you get no warning here. Personally I ran into it in some test cases that were trying to provoke deadlocks in async code. It took me forever to figure out why they weren't deadlocking 😅

I'm not sure what the more general behavior is that I'd like to lint here. Does Clippy already have a notion of "objects that tend to be captured for their Drop side effects"?

Start with the Rust example in the issue and review Clippy's existing async and Drop-related lint behavior. Determine whether the intended scope is unawaited async locks or a broader class of values captured for Drop side effects; done should include an agreed lint scope and coverage for the demonstrated case.