Implement async generator based Voila get handler

[davidbrochart]

References

This change is already part of #984, which will have to be rebased when this PR gets in.

Code changes

This PR aims at having a Voila get handler that is less coupled with Tornado. This handler streams HTML snippets as they are produced by the notebook execution. Instead of directly writing the HTML snippets with Tornado-specific methods (write and flush), we generate (yield) them with an async generator. This allows to use this generator e.g. with a FastAPI StreamingResponse.

cc @SylvainCorlay

[github-actions]

👈 Try it on binder (branch davidbrochart/voila/async_generator)

[github-actions]

Benchmark report

The execution time (in milliseconds) are grouped by test file, test type and browser.
For each case, the following values are computed: min <- [1st quartile - median - 3rd quartile] -> max.

Results table

Test file	basics.ipynb	bqplot.ipynb	dashboard.ipynb	gridspecLayout.ipynb	interactive.ipynb	ipympl.ipynb	ipyvolume.ipynb	multiple_widgets.ipynb	query-strings.ipynb	reveal.ipynb
Render
chromium
actual	3110 <- [3197 - 3456 - 3885] -> 5082	2499 <- [2569 - 2710 - 2854] -> 3139	2699 <- [2716 - 2782 - 2878] -> 3195	3267 <- [3280 - 3348 - 3481] -> 3713	2011 <- [2029 - 2031 - 2052] -> 2320	4421 <- [4588 - 4919 - 5561] -> 7516	8340 <- [9148 - 9303 - 9335] -> 9612	10242 <- [10260 - 10297 - 10321] -> 10377	1486 <- [1555 - 1595 - 1595] -> 1613	2757 <- [2850 - 3016 - 3292] -> 4572
expected	3379 <- [3442 - 3517 - 3701] -> 3876	2976 <- [3227 - 3321 - 3421] -> 3604	3608 <- [3623 - 3709 - 3793] -> 3825	4453 <- [4453 - 4523 - 4661] -> 4748	2559 <- [2655 - 2656 - 2660] -> 2674	3982 <- [4079 - 4213 - 4356] -> 4743	12183 <- [18509 - 19553 - 20811] -> 21515	15319 <- [15660 - 15796 - 15912] -> 16056	1517 <- [1920 - 1997 - 2103] -> 2113

❗ Test metadata have changed

--- /dev/fd/63	2021-12-23 10:41:36.976015823 +0000
+++ /dev/fd/62	2021-12-23 10:41:36.976015823 +0000
@@ -4,37 +4,37 @@
     "BENCHMARK_REFERENCE": "actual"
   },
   "browsers": {
-    "chromium": "97.0.4666.0"
+    "chromium": "94.0.4595.0"
   },
   "systemInformation": {
     "cpu": {
-      "brand": "Xeon® Platinum 8272CL",
+      "brand": "Xeon® E5-2673 v3",
       "cache": {
         "l1d": 65536,
         "l1i": 65536,
-        "l2": 2097152,
-        "l3": 36700160
+        "l2": 524288,
+        "l3": 31457280
       },
       "cores": 2,
       "family": "6",
-      "flags": "fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx avx512f avx512dq rdseed adx smap clflushopt avx512cd avx512bw avx512vl xsaveopt xsavec xsaves md_clear",
+      "flags": "fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm invpcid_single pti fsgsbase bmi1 avx2 smep bmi2 erms invpcid xsaveopt md_clear",
       "governor": "",
       "manufacturer": "Intel®",
-      "model": "85",
+      "model": "63",
       "physicalCores": 2,
       "processors": 1,
       "revision": "",
       "socket": "",
-      "speed": 2.6,
+      "speed": 2.4,
       "speedMax": null,
       "speedMin": null,
-      "stepping": "7",
+      "stepping": "2",
       "vendor": "GenuineIntel",
       "virtualization": false,
       "voltage": ""
     },
     "mem": {
-      "total": 7289614336
+      "total": 7291699200
     },
     "osInfo": {
       "arch": "x64",
@@ -42,11 +42,11 @@
       "codename": "Focal Fossa",
       "codepage": "UTF-8",
       "distro": "Ubuntu",
-      "kernel": "5.11.0-1022-azure",
+      "kernel": "5.8.0-1040-azure",
       "logofile": "ubuntu",
       "platform": "linux",
       "release": "20.04.3 LTS",
-      "serial": "ee60807b737b446ab066121536186e58",
+      "serial": "cfc067bfcb844f35865e279a1b0e66c5",
       "servicepack": "",
       "uefi": false
     }

[trungleduc]

Thank @davidbrochart, I will be very useful for the integration of fps!
I quite like your implementation of an independent "get generator" in #984 and it looks like we can do the same thing for get_generator here. What do you think?

[davidbrochart]

Do you mean the get handler method being extracted from the class? I so, maybe in another PR?

[trungleduc]

Yes, and in the next PR is a good idea too!

[davidbrochart]

Ready to merge this one?

[trungleduc]

Yes I think so, only question left is how to target this PR to 0.3.1 since we are already in the RC phase for 0.3.0. Maybe @jtpio will have some insights?

[jtpio]

Looking at the diff, it looks like a change affecting the core logic of the main render handler.

So I would say a bit late for an rc (normally focused on bug fixes), unless we consider this change as a bug fix.

[davidbrochart]

No, it's not a bug fix.

[trungleduc]

So we will wait for 0.3.0 (hopefully in 2 weeks ) before merging this PR?

[trungleduc]

@jtpio I'm going to merge this PR, do I need to create a 0.3.x branch before merging it to main?

[jtpio]

I think we can keep main targeting the 0.3.x release series for a while before creating a new branch.

[trungleduc]

Rebase to get the UI test fixes

[trungleduc]

Thanks @davidbrochart !