Refactor Quick Actions to prepare for better data enrichment

[FelixMalfait]

I had written a quick proof of concept for quick actions but we need to refactor this into something cleaner.

Here are the steps I would take:

• Simplify ExecuteQuickActionOnOneResolverFactory so that its role is mostly limited to calling QuickActionService (we’ll move the logic there)
• In QuickActionService, there should be an array of services that we will call to see if they have a GetQuickAction methods, and return the combined array from all services. For now the only service that will record quick actions is RecordEnrichmentService. A new service that has to be created. So the role of QuickActionServices is to manages the dispatch, taking the action name and calling+returning the right function call from the underlying service.
• The new RecordEnrichmentService is a parent service for sub-services: For example there will be RecordEnrichmentProviderApolloService and RecordEnrichmentProviderTwentyService (Apollo.io is a data enrichment service). It implements a getQuickActions method similar to the one on QuickActionService in the sense that its role is mostly to merge arrays from method calls on the quick actions providers.
• RecordEnrichmentProviderXXXService can implement enrichCompany and enrichPerson functions. That’s where we’ll put most of the business logic for data enrichment That’s also where we register the quick actions. GetQuickActions should return something like this: [“companies”: [{“label”: “Enrich with Apollo”, action:“RecordEnrichmentProviderApolloService@enrichCompany”}, icon: “IconLetterA”}, {...}] “people”:[...] “*”: [..]]

Note: as of today the business logic is separated into two parts. The QuickActionService handles most of the business logic (function calls orchestration, data fetching and persistence). While provider-specific implementations have been moved to an IntelligenceService. If we wanted to replicate that while moving the logic to the new RecordEnrichmentProvider model, it would mean similarly that some of the abstraction logic common to every provider would go into generic method on RecordEnrichmentService, and RecordEnrichmentProviderApolloService would focus on logic specific to the provider (api calls, etc.)