Refactor run_in_threadpool to seperate binding from execution

[adriangb]

This separates the conversion of func to an await able run in threadpool from the actual execution of that awaitable.

This change led to a nice homogenization of the take any sync/async callable/cm and make it an awaitable that FastAPI does: https://github.com/adriangb/anydep/blob/main/anydep/concurrency.py

So while this has no immediate advantage for Starlette, I think it gives developers of downstream packages more flexibility, and it also has no negative impact on Starlette.

[JayH5]

Hey 👋 these PRs around the concurrency stuff seem potentially like useful changes, but I think we'd be better off discussing them in an issue or discussion.

This PR in particular we're unlikely to merge since we'd actually like to reduce the API surface of the concurrency module (possibly even making it an internal module at some point).

[adriangb]

Makes sense to discuss. Do you want me to open an issue given that we already have this PR?

Reducing the surface area makes sense, I agree that these sort of utilities are best kept as internal. Might be a bit late though given that downstream packages like FastAPI already depend heavily on this module.

For this PR in particular, how about making the new method a private _ method? It doesn't help downstream packages but it might help Starlette internally and eventually lead to deprecation and replacement of the current run_in_threadpool method.

That said, this PR increases the surface area by 1 method, but also reduces an existing one to a 1 line wrapper, so it's practically a net zero change

[adriangb]

I'll close this as it doesn't seem likely to get merged and doesn't really add any value to Starlette itself