Feature/key server revamp

[sstruzik]

Revamping of the Key service.

For historical reason, the production of the key files were base on a module "lookup" that needed to return the keys as an iterable of dictionaries.
Although the lookup could be customized by model developer, the processing and the writing of the key file itself was part of Oasis code and therefore not changeable by model developer.
The writing itself was based on the construction of two lists for susses and error keys that could completely fill up the memory.
Finally, for model using dataframe writing the files could in fact be done directly via to_json or to_csv

With this first part of the work we plan on the Key Generation, our goal is to allow user a total customization of the key service (responsible for the generation on the key files) and also provide an efficient built-in implementation (improving the functionality of the lookup factory) that will satisfy most use cases.

Lookup Factory and new Key Server Interface

The key files writing process was mainly managed by the Lookup factory. We transfer this role to a new class that we call KeyServer, that will be returned by the factory and customizable in the config via the key 'key_server_module_path'.
The role of the Factory is simply to load the config and create the correct Key Server Object
To work properly, the Key Server class must implement lookup.interface.KeyServerInterface

As we simplified and generalize the lookup interface, some of the parameter passed to the Lookup Factory are now deprecated

• complex_lookup_config_fp => pass the path to your complex lookup config directly in lookup_config_fg
• lookup_module_path => set as key 'lookup_module_path' in the lookup config
• model_keys_data_path => set as key 'keys_data_path' in the lookup config
• model_version_file_path => set the model information ('supplier_id', 'model_id', 'model_version') directly
  into the config

BasicKeyServer

this new class is the basic implementation of the Key Server interface provided as a built-in by Oasis.

• It will use built-in or custom KeyLookup to process each Locations.
  These KeyLookup object must implement lookup.interface.KeyLookupInterface a merge interface between the now deprecated lookup.interface.OasisLookupInterface and the built-in lookup (for compatibility reason OasisLookupInterface is still supported).
  To determine if the lookup to be used is custom or built-in, we check if lookup_module_path is provided in the config dictionary
  if self.config.get('lookup_module_path'):
• The writing method have been adapted to be able to process the keys by chunk if applicable thus limiting the memory needed.
• It also provide a multiprocessing option that can be used if the KeyLookup has the process_locations_multiproc method. In most case simply using the mixin class MultiprocLookupMixin should work out of the box.

Lookup interface

Change have been done to the lookup Interface to be able to merge built-in and custom lookup. The main difference for custom lookup is in the init method.
The new interface is lookup.interface.KeyLookupInterface also BasicKeyServer still support lookup.interface.OasisLookupInterface

we provide a mixin method MultiprocLookupMixin that provide the possibility to use multiprocessing in BasicKeyServer.
The only requirement to use this mixin is that the method process_locations always return the same keys for a location.
This should be true for most models.