* Deprecates ModuleSystem can_execute_unsafe_code, get_python_lib_zip and cache properties
* Adds a new CacheService and SandboxService to provide the deprecated property
* Adds tests for the added CacheService and SandboxService
* Updates the ModuleSystemShim tests in Lms and Studio
- Updating Python Requirements
- Fix cache key generation to use class name and module
This was stringifying the class object directly, resulting in cache keys
like `:1:<class 'xblock_django.models.XBlockConfiguration'>.xblock_django.api.deprecated_xblocks`
which then cause breakage when Django 2.2.13 validates the keys.
Co-authored-by: edX requirements bot <testeng+edx-requirements-bot@edx.org>
Updating to the current highest number instead of making it the default
which is highest know by the language. This is beacuse when we update
between python versions if there is a new proctocol version, we don't
want that to cause cache thrashing as we try to load things from the
various caches. We can get into a situation where new machines pickle
things with a newer versions of the procotocl, put them in the cache and
then break older machines that don't know about the new protocol
version.
HIGHEST_PROTOCOL will cause it to change when we move from python 2 to 3
and this may cause issues as older machines try to read objects pickeld
with a version of the protocol they don't know.
During deploys, and if we have to roll back are two examples.