Allow periods in arguments to be ignored when parsing cacheKeys

[Iron-Ham]

This PR closes #1071 by introducing a regular expression when targeting the components of a CacheKey. Instead of simply splitting on ., we use a regular expression that matches . only if it is not contained within parentheses.

Performance:
As far as performance goes... maybe this isn't the best way to go about quantifying that, but it seems that any performance hit here is... trackable, but perhaps pretty negligible?

[calvincestari]

@Iron-Ham was that performance screenshot from a test run on your desktop? Judging by this it looks like the oldest iPhone apollo-ios would support (iOS deployment target is 12.0) is an iPhone 5s. It would be great to run that same quick-dirty test on a physical older device if possible.

[Iron-Ham]

@calvincestari can do!

[AnthonyMDev]

@Iron-Ham Thanks for this. I'm still a bit concerned about the performance implications, just because these cache key functions are called many times during the execution of GraphQL operations.

We have some rudimentary performance tests in the repo. I'm going to run those and see if I can get a better idea of the impact of this.

I'd also like to see more test cases to ensure this regex is correct. One test for the happy path is great, but are we certain that this is correctly ignoring . in all places outside of the arguments?

[AnthonyMDev]

After running our performance tests, it doesn't seem to create a noticeable regression, so I'm for merging this in. @Iron-Ham would you be willing to provide a few more test cases, to ensure that this only ignoring . within the arguments and that everything else still works correctly. I'm pretty certain it does, but would like to have the test coverage for posterity.

[Iron-Ham]

Writing this down for future track-ability, as this was originally posted on Slack:

I spent time reading up on the documentation around NSRegularExpression. Using regular expressions will not work for all cases given the flavor that NSRegularExpression uses: ICU. ICU doesn't support: recursion, non-fixed-width lookbehinds, or control-verbs. That means it cannot handle certain cases of nesting.

The original solution produced the following outputs:

Input: my.chemical.romance 
Output: ["my", "chemical", "romance"]

Input: my.chemical.romance(the.hidden.albums)
Output: ["my", "chemical", "romance(the.hidden.albums)"]

Input: my.chemical.romance(the(very).hidden.albums)
Output: ["my", "chemical", "romance(the(very).hidden.albums)"]

Input: my.chemical.romance(the.(very)hidden.albums)
Output: ["my", "chemical", "romance(the", "(very)hidden.albums)"]

Note that the final example is wrong: The last two items in the array should be one string. The ICU regex spec only supports known-count nesting, so supporting one degree would look like this: \.(?![^)(]*(?:\([^)(]*\)[^)(]*)*\))

Instead, we should create these tokens by just scanning the string manually. I've written up a few test cases that reflect desired behaviors and cover cases of string inputs that contain parentheses and whipped up a quick&dirty solution.

[Iron-Ham]

Maybe this isn't the best name for this since this isn't strictly checking for balanced parentheses pairs.

[AnthonyMDev]

This LGTM! Anything else that needs to be done here before merging it in?

[Iron-Ham]

@AnthonyMDev not afaict, so if you're good with it: merge away!

[AnthonyMDev]

Thanks so much for this contribution @Iron-Ham!