#5428 Epic/config management refactoring

IMPORTANT NOTE

Because this PR is so large in scale, as previously agreed with the Hummingbot Foundation, the procedure to its merging will differ slightly.

Foundation QA, please hold off on merging other PRs prior to this one as this will be sure to cause lots of merge conflicts.

Also, as soon as sufficient votes are attained for this PR, it will be merged to avoid holding up other PRs any longer.

Description

This PR lays the foundation for a refactor of the configuration management of hummingbot.

The new approach uses pydantic models to define the configuration maps. Aside from built-in validation functionality, this approach also allows the automatic generation of JSON schemas which is a big first step in the direction of decoupling the bot from its interface. Another major step in that direction is significantly restricting the use of global variables when dealing with the global config map (now renamed to client config map) and the AllConnectorSettings class.

The approach to storing and retrieving secure configs has also been refactored. We no longer store secure configs in the client config map (former global config map). Those are only stored in the Security class (which is still unfortunately accessed globally). In addition, the secure values are no longer stored separate from non-secure configs — they are both part of the same config map and stored in the same yaml file.

Two of the strategies, AMM and XEMM, were already adapted to the new configs style. The rest remain to be adapted. To accommodate for legacy configs, some of the legacy config management code still remains. If the legacy functionality is an entire function, then the function has been renamed with a _legacy postfix. If the legacy functionality are lines of code part of an otherwise non-refactored routine, then a comment # legacy was added. This was done to later facilitate complete removal of legacy config code.

The Pydantic model now allows for nested config maps. This is used for two purposes. First, it is used to provide more organizational structure as with the color map, which is now a nested sub-model of the client config map. Second, it is used to provide conditional requirements for the configurations (i.e. "field foo is required only if field bar is est to the value X). An example of this is the AvellanedaMarketMakingConfigMap.execution_timeframe_mode field.

A legacy migration routine was included on the bot's startup, which will detect if the bot is being ran for the first time since the upgrade, and will guide the user through the migration of the refactored configs. The routine will start by creating a backup of the current state of the configs folder, and proceed from there. It will also alert the user if any config map migration failed along the way.

The folder structure of the configs has been further split into connectors and strategies for better organization.

Link: https://github.com/hummingbot/hummingbot/pull/5428