fix(project config): Don't mutate the datafile object

[mjc1283]

Summary

createProjectConfig was destructively mutating its datafile argument. After that mutation, the datafile object could not be re-used to create another instance.
With this change, createProjectConfig copies the objects it needs to mutate and mutates only those copies. It's not a full deep clone; it only shallowly clones audiences, experiments, feature flags, groups, rollouts, group experiments, and rollout experiments.

Test plan

• Updated & new unit tests
• Compatibility suite should pass

Issues

https://optimizely.atlassian.net/browse/OASIS-6301

[mikeproeng37]

This could end up needing to be updated as we change datafile schema in the future. Would it make sense to roll our own cloneDeep function using recursion like it's done here: https://gist.githubusercontent.com/djD-REK/e8b1497e7fbf0374e4eada669e5609cf/raw/7ed3903084c6f309a5fe4456512dfb473504e919/Custom%20deep%20copy%20function%20using%20recursion.js

I found it in this blog heh: https://medium.com/javascript-in-plain-english/how-to-deep-copy-objects-and-arrays-in-javascript-7c911359b089 --> it's option 3

[mjc1283]

@mikeng13 Yea, that'd probably work. But we know what the datafile schema is, we don't need to handle arbitrary objects. The datafile schema does not change very often, and when it does, we don't necessarily need to change this code. Overall I think the project config module could be a lot cleaner, but it would require careful refactoring of many other modules, so not trying to tackle it now. I think we can set it up so nothing is mutated, and we create fast lookup objects/Maps separately from the datafile.

[mjc1283]

Put another way, copying/cloning is only required because we are mutating the datafile object. But there is no inherent need to mutate the datafile object. I think we can refactor so that it's nothing is mutated, and nothing is copied.

[mikeproeng37]

Hmm.. I think even if we don't mutate the datafile, customers could end up inadvertently mutating it and causing issues. I think cloning it for safe use makes sense.

[mikeproeng37]

lgtm

[mjc1283]

That's a fair point (cloning for safety). I didn't look too closely at the Medium post. Earlier I had my eye on this npm library rfdc. I think we could include a forked snippet from that (don't need all its features) and would only add about 50-100 LOC.

[jamesopti]

That's a fair point (cloning for safety). I didn't look too closely at the Medium post. Earlier I had my eye on this npm library rfdc. I think we could include a forked snippet from that (don't need all its features) and would only add about 50-100 LOC.

This would be my preference in the medium term, but the current fix is OK by me for now!
Could that utility also replace our Object.assign polyfill?