feat(spack_operation): implement setup_spack_env functionality

Following changes have been incorporated:

• SpackOperation.py: The handle_result and trust_gpg_key methods were specifically updated with tests and docstrings. Also modified the add_mirror method as per the changes.
• SpackOperationUseCache.py: Similar to SpackOperation.py, this file also got enhanced tests and docstrings, specifically for the setup_spack_env method. The focus is on setting up the environment for a user spack cache setup along with testing of the caching behavior and improving documentation.
• BuildCacheManager.py: This file saw improvements in its test suite and the addition of docstrings. The tests likely cover various cache operations, and the docstrings explain the purpose and usage of the cache management methods. The get_public_key_from_cache, download, _log_warning_if_needed, and other methods were updated with tests and docstrings.
• .gitlab-ci.yml: Changes likely include adding or modifying stages for running the new pytest tests and generating coverage reports.
• pyproject.toml: This file was modified to add testing dependencies required for the enhanced test suite. Specifically, pytest, pytest-mock, pytest-ordering, and coverage were added under the test extra. This change enables running the new tests and generating coverage reports.

The commands folder implements a command execution and management system, especially for Spack, using these key components and patterns:

• Command Definitions (Enum/Constants): command_enum.py likely defines an enumeration (or constants) representing different commands. This promotes type safety and avoids stringly-typed code.

• Command Sequence Builder: command_sequence_builder.py implements the Builder Pattern to construct CommandSequence objects (from command_sequence.py). This allows for flexible and readable creation of complex command sequences.

• Command Sequence: command_sequence.py represents a sequence of commands to be executed. It encapsulates the order and configuration of commands.

• Spack Command Factory: spack_command_sequence_factory.py uses the Factory Pattern to create Spack-specific CommandSequence objects. This centralizes the creation logic for different Spack commands and simplifies their usage. It likely uses command_sequence_builder.py internally.

• Generic Command Runner: A command_runner.py (implied, not explicitly mentioned in the diff) likely handles the actual execution of commands, possibly using subprocesses. This abstracts the execution details from the command sequence logic.

• Bash Command Executor: Executes a sequence of commands in a Bash shell, handling various potential errors and returning the output and error message (if any).

• Focus on Spack: The structure strongly suggests a focus on managing Spack environments and packages. The factory and command definitions likely reflect common Spack operations.

Patterns used:

• Enum/Constants Pattern: Used for defining distinct command types.
• Builder Pattern: Used for constructing command sequences.
• Factory Pattern: Used for creating Spack-specific command sequences.
• Command Pattern: A close variant of the Command Pattern for encapsulating command execution. Abstraction of shell commands along with an invoker (command_runner) been implemented

Parent artefact: https://tvb-projects.atlassian.net/browse/VT-70

dedal/spack_factory/SpackOperationUseCache.py

 import os
-
 import subprocess
 from pathlib import Path
 
@@ -9,8 +8,7 @@ from dedal.error_handling.exceptions import NoSpackEnvironmentException
 from dedal.error_handling.exceptions import SpackInstallPackagesException
 from dedal.logger.logger_builder import get_logger
 from dedal.spack_factory.SpackOperation import SpackOperation
-from dedal.configuration.SpackConfig import SpackConfig
-from dedal.utils.utils import file_exists_and_not_empty, run_command, log_command, copy_to_tmp, copy_file
+from dedal.utils.utils import file_exists_and_not_empty, run_command, log_command, copy_file
 from dedal.wrapper.spack_wrapper import check_spack_env