Initialization via Job Packet and Rename DataQueueHandler to DataProvider

[Romazes]

Description

1. Feature Enhancement: Initialization via Job Packet

• Implements initialization functionality through Job packets, enhancing the efficiency and flexibility of the system.
  Provides a streamlined method for initializing processes, improving overall performance and maintainability.

2. Code Refactoring: Renaming DataQueueHandler to DataProvider

• Renames the DataQueueHandler class to DataProvider for improved clarity and consistency in naming conventions.
  Enhances code readability and understandability, aligning with best practices for naming conventions.

3. Use Globals for credentials access for subscription validation.

• This follows Consolidate Configuration.Get usages Lean#7796

Related Issue

N/A

Motivation and Context

1. Feature Enhancement: Initialization via Job Packet

• As the system evolves, there is a growing need for a more robust and flexible initialization process. Implementing initialization through Job packets provides an efficient and adaptable solution, enhancing overall system efficiency and maintainability.

2. Code Refactoring: Renaming DataQueueHandler to DataProvider

• Clear and consistent naming conventions are crucial for improving code maintainability. Renaming DataQueueHandler to DataProvider aligns with best practices, improving code clarity and making it easier for developers to understand and work with the codebase.

Requires Documentation Change

N/A

How Has This Been Tested?

To ensure the robustness and correctness of the Job initialization process, the PR have been implemented specific test cases.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• Refactor (non-breaking change which improves implementation)
• Performance (non-breaking change which improves performance. Please add associated performance test and results)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Non-functional change (xml comments/documentation/etc)

Checklist:

• My code follows the code style of this project.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description>

[Martin-Molinero]

Thank you! 👍