The ASYNC100-version of ASYNC91x, i.e. the trivial case where there is no await/async [for/with] in a method at all. As opposed to ASYNC91x this could be default-enabled, will be relevant for asyncio users, and should be much less noisy.
We could silence 910 and 911 for the trivial case to mirror async100/async912, or expect users to disable async-func-no-await when enabling 910 & 911.

Examples:

# currently raises 910, would raise async-func-no-await
async def foo():
    print("bar")
# would only raise 910
async def bar():
    if ...:
        await foo()
# async-func-no-await does not care about func vs generator
# raises 911 and async-func-no-await
async def foo_gen():
    yield "hello"
# does not give any warnings
async def foo_always():
    if ...:
        await foo()
    else:
        await bar()

Shoutout to @oremanj for giving inspiration for it in gitter.

I think it is still a good idea for linters to insist that every async function await something, because async functions are more expensive to call than synchronous functions, and if it doesn't await anything then it should just be synchronous. In order to get a checkpoint guarantee you need to await something on every path; this is definitely helpful if you use Trio (or if you're writing an anyio library that people might use on Trio), but it's hard to argue that it provides any meaningful benefit on asyncio when the built-in functions don't follow the rule.