Support custom IOLOOPs

[gnir-work]

Summary

This is merge of two PR's

1. Allow passing a custom loop setup function instead of None #2391
   Support passing a custom IOLoop setup function in order to support running uvicorn in custom ioloop implementation other that the default and uvloop.
   For example this feature will allow using this monitored IOLoop inside uvicorn applications :)
   Link to discussions thread - Add support for custom ioloop implementations #2256

2. use asyncio.run(..., loop_factory) to avoid asyncio.set_event_loop_policy #2130
   set_event_loop_policy will be deprecated in python 3.13 and uvloop.EventLoopPolicy is deprecated already, this backports and uses the preferred loop_factory keyword to configure asyncio.run

Checklist

• I understand that this PR may be closed in case there was no previous discussion. (This doesn't apply to typos!)
• I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change.
• I've updated the documentation accordingly.

[gnir-work]

Not sure why @graingert removed this from here, please make sure its ok :)

[graingert]

the setup_event_loop method is removed, so we don't need to call it in init_process. We also don't need to have a method just to call super - that's the default

[gnir-work]

Any updates regarding this? @Kludex

[gnir-work]

Hey guys,
Would really love to push this one forward.
We are currently having a real hard time integrating IOLoop monitoring because of the hacks needed when running a custom IOLoop implementation

Thanks :)

[gnir-work]

@Kludex Are you a maintainer?
I would really love to merge this functionality (given the green light on merging this I will fix the unit tests that seem to have broken over time)

[Kludex]

Reference for me later: python/cpython#122240

[graingert]

this is a bit more important to get done as 3.14 deprecated the policy system, and we need a way to enable eager tasks

[Kludex]

Question to my future self, or others:

Just to confirm, this is not a breaking change, given that --loop is currently not accepting a different loop other than asyncio and uvloop, right? Or is it?

[graingert]

Question to my future self, or others:

Just to confirm, this is not a breaking change, given that --loop is currently not accepting a different loop other than asyncio and uvloop, right? Or is it?

it should be not a breaking change.... mostly

there's some differences - we're not using the broken and deprecated policy system anymore so that means anyone using asyncio on windows from a thread will get the default asyncio.EventLoop in their asyncio.run calls, rather than the SelectorEventLoop.

There's another change in that setting the event loop factory to "not None" results in asyncio.set_event_loop() not being called, but this is a no-op on windows anyway. (We do still call set_event_loop on posix, where on old python versions on linux this has observable differences with how child watchers work)

[graingert]

@Kludex ok I've stopped fiddling with this PR now - it's good to be reviewed