Add support for custom ioloop implementations

[gnir-work]

Hey all,
I am currently developing a monitored ioloop.
The purpose of the project is to allow insights into the healthiness of a running ioloop, for example exporting with prometheus a histogram showing the execution time of each task on the ioloop.

I wanted to integrate this into our production FastAPI but saw that currently uvicorn only allows to pass two predefined loops (asyncio and uvloop).
What do you guys think about adding another CLI parameter called loop-factory which will contain an import path to a factory of type () -> BaseMonitoredEventLoopPolicy.
This will allow users to run uvicorn in any ioloop they choose to.

I am also ok with making it a fallback of the loop CLI param, however I find that implicit and confusing in my opinion.

I will be more than happy to open a Pull request in case you like the idea :)

[gnir-work]

After diving into the codebase and thinking about it some more we can get the same functionality by allowing passing none as a parameter for the --loop which will tell uvicorn to skip the setup process.
This was actually a feature back in 2019 but was removed due to the specific requirements of uvicorn when running on Windows.

This is a more lightweight solution which requires minimum implementation but allows power users to have more control over the execution environment of their asgi application.

[graingert]

I started work on using the loop_factory kwargs here #2130 I never got around to finishing it

[gnir-work]

Hey,
First of all thanks for the answer!

I took a look at the PR and it is indeed the direction I was going for.
I would love to finish the PR for you and add the ability to provide a custom ioloop factory as well.

Are you ok with me committing the changes on the same PR?
If not how would you like to go about this?

[rtpg]

I was about to start writing something like monitored-ioloop for my own debugging purposes, so mentioning that this would be quite helpful for me to debug some production issues

[gnir-work]

I opened a PR adding this logic to the refactor @graingert started doing to the IOLoop handing mechanism

Would really love to push this one forward.
Thanks :)