Virtual document updates are slow for large notebooks

[krassowski]

Description

As each letter typed triggers an update of the entire virtual document, it can be very expensive in notebooks with many editors (150+). Instead, it should only patch the VirtualBlock that has changed to minimise the delay - we should only rebuild the document on editors were moved around OR if a change of a virtual documents number inside the edited block was detected; this should help speed up the completer too (see #272). In addition, we need profiling to see what are the other bottlenecks.
Plan:

• create a test cases with a large notebook
  • measuring time in which virtual document gets created and updated
  • checking if completer works in such notebook
• add timeout to completer preparation step so that it falls back to the kennel completer of the LSP stops responding
  • test this!

Actually, the ability to do such hotpatching of virtual documents highlights why having the LSP at frontend rather than at backend might be beneficial - but only if we are not mirroring the documents on the disk (note: we could try to use ramdisk if available).

Context

• Operating System and version: Ubuntu 20.04
• Browser and version: Chrome 85
• JupyterLab version: 2.2.6

Required: installed server extensions

config dir: /home/krassowski/.pyenv/versions/3.8.1/envs/pelvic_pain/etc/jupyter
    jupyter_lsp  enabled 
    - Validating...
      jupyter_lsp 0.9.2 OK
    jupyterlab  enabled 
    - Validating...
      jupyterlab 2.2.6 OK

Required: installed lab extensions

        @krassowski/jupyterlab-lsp v2.0.0  enabled  OK
        @krassowski/jupyterlab_go_to_definition v1.0.0  enabled  OK