Break up the call_gws_providers() method into three submethods

[mitchelbaker-cisa]

Prerequisites

• This issue has an informative and human-readable title.

💡 Summary

The purpose of the call_gws_providers() is to call the relevant GWS APIs to get the data we need for the baselines.

At a high level the method performs the following steps:

1. Get all organizational unit data then add all OU names to a product_to_items aggregate dictionary
2. Gets the GWS admin audit logs and merges them into a product_to_logs aggregate dictionary
3. Repacks the main aggregator into its original form that the API returns the data in which is under an items key, then this key is placed under a {product}_log key for the Rego code

call_gws_providers() returns product_to_items as a response. Therefore, it should be possible for ths method to be broken down into smaller chunks as long as the new methods are called in the same sequence.

Motivation and context

In its current form, the method is difficult to unit test.

Implementation notes

1. Break up the call_gws_providers() into smaller chunks. The method is already broken up into three distinct try/catch blocks.
2. call_gws_providers() should still be returning the final product_to_items dictionary as a response.
3. Make sure these new methods are unit tested.

Acceptance criteria

• call_gws_providers() is broken up into smaller chunks that can be unit tested.
• Regression testing verifies Rego checks and other parts of the codebase that rely on the provider output operate as expected.