Implement event history insert and insertIfNotExists consequence support

[timkimadobe]

Description

This PR implements support for the new insert and insertIfNotExists consequence support in the Core RulesEngine, leveraging the existing rules condition evaluation logic to trigger these consequences.

The consequence handling has been updated to handle the new schema consequence type, and https://ns.adobe.com/personalization/eventHistoryOperation schema value.

At a high level, the consequence object has three high level properties:

Name	Key	Type	Description
Operation type	operation	string	Required Determines the type of database operation to be performed on Event History by the SDK. - Insert: Inserts a record in the Event History Database. - Insert if not exists: Inserts a record in the Event History Database only if there is not already a matching record with a matching hash value.
Key-value pairs	content	object	Optional Provided key-value pairs will be added to the string used to generate the event history hash. If the value represents a token that the SDK knows how to resolve, the resolved value will be used (such as shared state values, ~timestampu, etc.).
Event Data Mask	keys	array	Optional An array of strings that designate which keys in the event will be used for generating the event history hash.

The primary logic for this new support is handled in the new LaunchRulesEngine processEventHistoryOperation method:

1. Checks that the required property of operation exists (which could be either insert or insertIfNotExists, but does not strictly require these two values for future expansion)
2. The consequence's keys are separated into two groups - event data keys and token keys: -
   • Token keys: keys that are prefixed with ~ (ex: ~sdkver)
   • Event data keys: All other keys
3. Token keys are reformatted and resolved
   1. Each token key is placed into a new dictionary where the key is the token and the value is the token wrapped in the LaunchRulesEngine token delimiters
      • ["~sdkver": "{%~sdkver%}"]
        2 This dictionary is resolved using the TokenFinder used to resolve the original rules condition
4. The historical event to be recorded's event data is set up with the original triggering event's data payload
5. The token key dictionary is merged into the data dictionary
6. The consequence's custom content key value pairs are merged in (the content key value pairs' tokens were already replaced by the overall consequence resolution)
7. The event mask is set up with all of the keys from keys (that is, event data keys and token keys) and content
8. Create the historical event to be recorded with the merged event data and final mask
9. If insertIfNotExists, first check that the hash for the event does not already exist
   • NOTE: A new API, eventExists has been created in in EventHistory to support easily checking for the hash value instead of having to extract all the key value pairs from the flattened map as is required by the existing getEvents API's EventHistoryRequest input format requirement
10. Insert the historical event into the record

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.