Avoid synchronous code within IDOM

[Archmonger]

Old Behavior

Currently, IDOM relies on synchronous code to properly queue renders. This code blocks the asyncio event loop, causing massive concurrency issues.

See section "Two Worlds of Python" for why this is a problem:
https://arunrocks.com/a-guide-to-asgi-in-django-30-and-its-performance/

New Behavior

Rewrite parts of IDOM core to do everything using asyncio.

Implementation Details

Anything that relies on order of operations should be executed in a FIFO queue.

If synchronous code is required, it should be run in a thread in order to avoid blocking asyncio event loops.

All synchronous functions should be converted to async within IDOM core.

I had previously attempted threading the django-idom dispatcher as a quick fix, but that did not yield worthwhile performance benefits, likely due to context switching.

Code of Conduct

• I agree to follow the Code of Conduct.

[Archmonger]

@rmorshea Can we transfer this to idom-team/idom as a v2 goal.

Also, I personally consider this one as P0 since it demolishes the performance of any ASGI webserver.

[rmorshea]

I think we should create a more generic research task within IDOM core to investigate the best ways to improve performance (if there isn't one already). There may be other ways to make things faster (e.g. improving/removing VDOM diffing).

We should also create a task to benchmark the performance of IDOM within django-idom (i.e. see how much time IDOM contributes to a render vs Channels/Django).

[Archmonger]

reactive-python/reactpy#557 exists for generic performance improvements to rendering performance, but profiling isn't going to tell us the whole story. The issue in this scenario is concurrency, rather than performance.

The issue is visually pronounced enough to notice. For example, using the django-idom tests and opening two separate webpages concurrently, you can see them render serially fairly slowly, and console logs show WS connection accept being delayed during renders.

I'm not really sure how to benchmark multi-client websocket concurrency. I'll need to do some research and probably update the title/description of that issue.