feat(AP-2173): Add persistence to context

[tfoster]

This change allows an implementer to designate context keys to persist in either local or session storage.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[mattstrom]

Unit tests would be good too if you can add some.

[mattstrom]

There's an argument to be made that these changes belong in asset-manager since they are browser-specific. Though, I understand it was probably more straightforward to implement here. However, there might be some privacy and compliance considerations we need to observe.

asset-manager has a class named EvolvStorageManager which is responsible for allowing persistence only after consent has been granted. We probably need to observe consent here too.

See evolv-ai/asset-manager#186

[robertsevernsentient]

Placing our whole context onto session and local storage concerns me as it dramatically increases the information that we store on a cookie like area -- that customers ask for information on when we go through security reviews -- so it should at least be optional

We also make this information available to chrome plugins

The other concern is that this makes the functionality specific to the client -- could be argued that is ok, given a true sdk implementation, the dev controls the lifecycle, and this code will be ignored in npm. But we've previously managed to browser specific implementations to asset manager

Also -- tests

[robertsevernsentient]

javascript-sdk currently has no references to session or local storage. Is this check to prevent errors if we're running on node?

A warning here that persisting is doing nothing would be good -- but should this capability live in asset-manager?

[tfoster]

Yeah, I'll add a warning.

[tfoster]

Placing our whole context onto session and local storage concerns me as it dramatically increases the information that we store on a cookie like area -- that customers ask for information on when we go through security reviews -- so it should at least be optional

We also make this information available to chrome plugins

The other concern is that this makes the functionality specific to the client -- could be argued that is ok, given a true sdk implementation, the dev controls the lifecycle, and this code will be ignored in npm. But we've previously managed to browser specific implementations to asset manager

Also -- tests

@robertsevernsentient I agree that we shouldn't persist the full context. This functionality allows the consumer to specify one or more keys to persist, not the full context.

I can add a warning about not persisting when executing in NodeJS. I could also make the storage pluggable, but the usecases for this would be limited server-side.