Introduce Account-level matching & mapping to allow supporting Account-level fields on PersonAccounts

[jbachelet-osf]

Introduction

This PR aims to introduce a new feature: Being able to match and map B2C customer profile attributes to Account-level fields from Core.

A bit of technical background: From the Core platform, a PersonAccount is a merge of both the Account and the Contact records. This means that a given PersonAccount record may have Account-level fields, and Contact-level fields. Before this new feature, b2c-crm-sync was only relying on Contact-level fields to ensure the same codebase between the Account-Contact model and the PersonAccount model.
The issue with this logic is that when a business requirement is to create a given field at Account level because it makes more sense, but the data has to be mapped from B2C Commerce, b2c-crm-sync was unable to make it working properly in a standard way. In order to make it work, we would have to duplicate the field at the Contact level and copy over the data between both Contact-level and Account-level fields in order for the data to transit from the Contact to the Account.

Now, b2c-crm-sync is able to get the account-level field from B2C Commerce, use it within the matching rule if needed, and also map it to the PersonAccount record that is being resolved by b2c-crm-sync.

Breaking changes

Changes have been made from within the root code of b2c-crm-sync to make this feature working for PersonAccounts only.
If you enable the PersonAccount model, then the code behaves in a way that

1. B2C to Core resolution -> the B2C customer profile data is filled within a PersonAccount instead of a Contact, and so the matching rule and duplicate rules which fires to resolve the right customer are the PersonAccount-based ones, and not the Contact-ones anymore. Thus, the Contact-based duplicate and matching rules are not used anymore within the code, they are only used by the unit tests.
2. B2C to Core mapping -> the B2C customer profile data is mapped to a PersonAccount directly, instead of being mapped to a contact and then merged to an account. This makes the data being able to be mapped to both Account-level and Contact-level fields at the same time.
3. Core to B2C mapping -> the customer profile data that needs to be synched back to B2C are applied in a way that the contact-level mapping are applied first, then the account-level mapping are applied on top of this mapped contact-level data. This ensures that contact-level mapping have the priority in terms of mapping. Then this merged mapping customer profile is sent back to B2C the same way as before.

Unit Test Coverage

Same as before, we ensure the solution is 100% passing unit test with a coverage higher than the required 80% for Core and 100% unit test coverage for B2C.

Use cases

Creation of the Account-level field

In order to make our use case working, we create an Account-level field:

Configuration of Integration Mapping

In order to make our use cases working, we create an integration mapping for an account-level mapping:

1 - Customer resolution (no existing customer in Core, so PersonAccount creation):

Creation of a brand new B2C customer profile, containing an account-level field:

The account is actually created within Core, including the account-level field:

2 - Synching back customer data from Core to B2C

Modifying the Core PersonAccount record:

The B2C customer profile is modified, including the account-level field:

3 - Customer resolution on an existing customer (removing the customer profile from b2c and creating it again, but leave the core profile as-is)

Creation of the B2C customer profile, containing the account-level field:

The existing Core PersonAccount is resolved and correctly mapped with both Contact-level and Account-level fields: