Stub generation for the Python client was implemented as a bit of an afterthought, and could be drastically improved.

Currently, the Python client dynamically constructs all of the stubs (classes, methods etc that when called will invoke the relevant RPC) when it first connects to the server. The client also has a collection of pre-generated .pyi files which attempt to attach static type information to these dynamically generated stubs.

This approach causes some issues. For example, L stubs can only be imported when type checking, not when running the code, because they are .pyi files with no corresponding (static) .py implementations.

A better approach would be to have the client operate in one of two modes:

• Static mode (by default). Stubs are used (pre-generated) - these a full .py implementations with type annotations. No dynamic code gen is necessary. (This might also give better performance).
• Dynamic mode that works as it currently does, with no static type information. (This mode is mainly needed when using the client before any stubs have been generated, as part of the build process. It's unlikely to be used by an end user.)

Note: we want statically generated stubs so that IDEs can provide things like auto-completion and type information.

We should also update the tests to run the client tests in both modes. Previously the .pyi type information was not tested.

Related issues #658, #626, #627