Experiment: Refactoring Azure SDK Client into Wrapper

[logyball]

When attempting to write out larger-reaching integration tests for the Azure Module of cloudcost-exporter, I was running into a bit of a wall with how the mocks currently work. This PR attempts to address that.

What

Move our internal use of the Azure SDK into its own package. The client(s) used will live in a Wrapper object that will be attached to the Azure object, which can be passed to individual Collectors for when they need to reach the Azure API.

Why

By decoupling the logic of reaching out to the Azure API, we can much more easily test the actual logic of the collectors.

Notes for reviewers

The git diff is a bit much. One way to look at this is through several components

Component One: Azure Client Wrapper

These changes are isolated to pkg/azure/azureClientWrapper/azureClientWrapper.go. They are fairly straightforward and are lifting the logic from the individual components (e.g. MachineStore-> getVmInfoFromVmss becomes AzureClient->ListVirtualMachineScaleSetsOwnedVms).

Component Two: Machine Store

Machine store has taken the logic that reaches out to the Azure API and deferred that responsibility to AzureClient. Notable places:

• getVmInfoFromVmss now uses azClientWrapper.ListVirtualMachineScaleSetsOwnedVms
• getVMSSInfoFromResourceGroup now uses azClientWrapper.ListVirtualMachineScaleSetsFromResourceGroup
• getClustersInSubscription now uses azClientWrapper.ListClustersInSubscription

Component Three: Price Store

• PopulatePriceStore now uses p.azureClientWrapper.ListPrices

Component Four: Testing

Testing can be seen fully implemented for a single function (as a PoC) in price_store_test.go -> TestPopulatePriceStore.

Downsides (and counterpoints)

• This is a slightly different approach than the other two collectors, but I think it makes it slightly easier to think about from a testing perspective
• There will be a need to implement more stubs to the client wrapper as the functionality grows
  • This should not be challenging. This functionality will already have to be implemented somewhere, might as well be the wrapper
• the Azure object must instantiate clients that it may not end up using, depending on which services are required
  • This is only a downside if the credentialing becomes a problem. I do not think this will occur, as credentials are checked server-side upon making a request, so unused clients are more of an annoyance than a true problem.

[logyball]

I don't love the naming of wrapper, I'd call tha

Currently staged, observing behavior. Nothing stands out at the moment as concerning but I'll keep an eye on it.

EDIT: no regressions observed after 24 hours. Merging!