Lazy restoration of cached modules

[MikhailArkhipov]

Currently module analysis is restored from the database as regular analysis with dependencies is running. I.e., instead of evaluating code, result is read from the database. This allowed to integrate caching into the existing analysis workflow (the dependency walk) easily, but, unfortunately, there is a drawback.

Namely, often IO operations (i.e. reading from the database) take almost as long as the original analysis. It is not the database performance issue, raw serialization into flat binary file and reading back is not much faster than binary JSON used by the LiteDB.

Changes:

• Instead of restoring everything, only main module (such as numpy) is restored. Module the claims to have no dependencies so analysis does not run on its submodules. This should provide first level of completions.
• Types coming from submodules should be kept lazy – for example, class that comes from a submodule, remains lazy. When deeper member is requested, such as when user types ‘numpy.A.’ where ‘A’ is from ‘numpy.core’, then ‘numpy.core’ analysis is restored from the db, and so on – on demand.
• Types that never used may never be restored yielding memory savings. Obviously, there may be hit for really complex members than chain multiple modules, but it should be one time hit.
• Top-level module database will then need to store more information about inner types (such as function signature and documentation rather than relying on fetching those off the inner restored type).

The approach does not require changes to the analysis workflow. If module is cached, it will be restored and if analysis of some non-cached module requires deeper members, process is the same as if user requested said members.

[MikhailArkhipov]

WIP update: system library restored, no analysis of its dependencies was performed at all:

[MikhailArkhipov]

#1753 affects couple of tests

[MikhailArkhipov]

#1533 may need to be fixed for tests at least.