PackageLoader loads classes with incorrect version spec if legacy package storage is used

[Alexander Tivelkov]

Consider a MuranoPL package having some version in its manifest, thus having all its classes to have the same version as well.
If the UI definition references classes of this package just by time (without a "class_version" key in UI definition) it defaults to the version spec "0", i.e. version range >=0.0.0,<1.0.0.
If the version of the package differs from this range (e.g. it is higher than 1.0.0) Murano should not use this class.

Actual behaviour differs if the legacy package backend (i.e. non-glare) is used: the client ignores the version spec part of the query and returns ANY version of the package having this class (actually this will be the only version of this package).
This version is used (which may lead to compatibility errors), but even worse - it later gets cached in the cache of the package loader, but it is cached by its actual version.
Subsequent calls to load the same class lead to checks of the cache with the requested (i.e. 0-based) version spec. When such class is not found, another attempt to load the class and package is made - and the same object is constructed for the second time and replaces the old object is the cache (since it has the same version).
This leads to loss of the last reference to the package object, which gets collected by GC. As a result, all package properties of type objects (represented as week references) become dead, which leads to a very hard to debug and diagnose runtime problems.