dts-scripts refactoring

The problem you're addressing (if any)

1) Bad scallability; a. No explicit coding rules and style -> the code is difficult to read and modify, the coding style of every contributor overlays with others, and the codebase shortly ; b. Not clearly separated systems -> the way the system works is not linear and, therefore, not clear, especially for novices; c. The language which is not suitable for large codebases -> language issues and workarounds; d. Configuration and metadata directly stored in the codebase -> not convenient to scale and support; 2) Awful testing and verification routine; a. No test cases prepared -> no empirical evidence of working features; b. No hardware separation -> QEMU cannot be used for testing and verification; 3) High entry level; a. No documentaion and comments; b. Highly non-linear structure (nonlinear logic should be separated from hardware-specific deployment logic, which should be clear step-by-step code);`

Describe the solution you'd like

Nodes and paths describtion:

Deployment - common provisioning logic (not tools or calls to the tools), the only module writing to hardware (via HAL), the common logic makes calls to a hardware specific logic (functions; 8) held by HAL. In case the testing is going on, the common logic instead of communicating with hardware via HAL communicates with mocking HAL functions (8), which emulate the hardware.
Configuration - logic responsible from getting and providing hardware information (2, 5). During the boot, it gets hardware inf (7). and keeps it, then, according to the inf. gained, it chooses (6) the DPP configuration (links to artifacts, lists of hardware specific mocking functions, lists of variables that define dpeloying workflows, etc.) from Linux FS (or, theoreticaly, from cloud services (then, it will have to communicate with packaging node first)).
User interface - is responsible for for communication with user. It has some hardware specific stuff (like, whether it is possible to update or to install, or both) on which its decides based on inf. provided by configuration node (5). Its provides user following functionalities: start deploying (1), start backup or restore (9) and manage packages (10).
Backup and restore - logic responsible for backing up and restoring firmware, takes full advantage of deploing logic (11) and its ability to communicate with hardware (8).
Packaging - responsible for checking DPP subscribtion with cloud services, logging in, downloading artifacts, and managing packages. Could be referenced by deploying logic (3) or explicitely by user (10).
Linux FS - holds some hardware-specific configs (that are currently held in board_config function) in .json files, as well as hardware-specific logic for HAL (some hardware-specific deploying functions and mock functions) and provides it on the start to configuration node (6).
HAL - Separates all logic from calls to tools, which manage hardware (13); holds some hardware-specific functions between calling to the tools (8) and the deploying logic, so to separate highly non-linear deploying logic from step-by-step hardware-specific logic. The hardware specific log is being dynamically linked depemding on the hardware being used (12), or being replaced by hardware-specific mock functions for tests on QEMU.

Where is the value to a user, and who might that user be?

TBD

Describe alternatives you've considered

No response

Additional context

No response

Dasharo / dasharo-issues