Refactor AnalyticsProvider

[atmamont]

Summary

The goal of this exercise is an exploration of refactoring approaches:

• The main goal is to remove extra responsibilities from the AnalyticsProvider (SRP). So far it has many responsibilities (always sending initial analytics data, deciding if to store/send analytic events depending on the configurations, caching logic, network requests creation, storing checkoutAttemptId, timer logic)
• moving logic branching based on the state (configuration.isEnabled) to the top level, reaching the assembly layer (aiming for AnalyticsProvider to become fully stateless), and splitting logic into smaller composable pieces easy to read and test. Branching logic is now distributed across multiple methods and can lead to developer mistakes in the future.

This is better to review by commits:

• https://github.com/Adyen/adyen-ios/commit/08402670dc292639af1d1460a4927cfe97c9a263 Identify common check and group of methods (configuration.isEnabled). Move the check to the top assembly layer, providing a no-op event data source in the case when analytics is disabled, reducing the number of checks.

I will follow up on this in small digestible chunks so we can collect feedback during the process.

Next steps

As we can now see, the final part of a business logic that sends events through the sendEventsIfNeeded() is also safeguarded with a similar check: guard configuration.isEnabled else { return } This gives me the idea that all current responsibilities of AnalyticsProvider in the case of disabled analytics can be narrowed down to a single responsibility to send an initial analytics request. Should this class be responsible for both sending initial analytics and on top of that managing network, cache, and event filtering logic? Probably, not, and the initial analytics call becomes a good first candidate for extraction.

Ticket

COIOS-777