FEAT: Store identity map to persist for subsequent calls

[Spencer-Smith]

Description

To help track identity for users that are not leveraging ECID, this feature stores the identity map made on send event calls so that it can be populated on follow-up calls (not originated directly by user, eg proposition display).

Related Issue

Jira

Motivation and Context

(see description)

Screenshots (if appropriate):

N/A

Checklist:

• I have signed the Adobe Open Source CLA or I'm an Adobe employee.
• I have made any necessary test changes and all tests pass.
• I have run the Sandbox successfully.

[carterworks]

This is huge and a great add. I have two small questions, but no real blockers.

[carterworks]

Suggested change

	if (xdm && xdm.identityMap) {
	if (xdm?.identityMap) {

[carterworks]

What do you think about something like this, to be able to clear the stored identity map? @jonsnyder & @dompuiu let me know your thoughts, too

if (xdm?.identityMap === null) {
  identityMapStorage.clear();
}

[jonsnyder]

This is a tricky feature. Consider this use-case:

1. sendEvent1 is sent with identityMapA
2. sendEvent2 is send with identityMapB
3. sendEvent1 returns, renders and sends a display notification
4. sendEvent2 returns, renders and sends a display notification

Ideally, 3 would contain identityMapA, but with this solution it has identityMapB.

I think to solve this, you would need to add the identityMap to the lifecycle onBeforeEvent call (at the top level or part of one of the params) and pass it through to the collect call.

[carterworks]

As-is, this attaches the identity map to a proposition display event (given that an identity map is provided when fetching/rendering the proposition) but it doesn't include identity map for automatic click tracking.

Requested changes have been implemented