Restrict DataDog request instrumentation to /cortex URLs

[canac]

DataDog's network request instrumentation was causing CORS errors for the designation content requests on branded checkout pages. DataDog was adding headers to the requests, which caused the requests to require a CORS preflight request, which was failing because AEM doesn't implement the OPTIONS method for requests to URLs like https://give.cru.org/content/give/us/en/designations/2/5/9/2/3/2592320.infinity.json. This change restricts instrumentation to cortex gateway URLs.

https://secure.helpscout.net/conversation/2422586630/1052239?folderId=7296729

[wrandall22]

just FYI @mattdrees ^

[canac]

Tested in staging by verifying that running fetch('https://give.cru.org/content/give/us/en/designations/2/5/9/2/3/2592320.infinity.json') doesn't add any additional x-datadog-* headers like https://www.jesusfilm.org/how-to-help/ways-to-donate/give-now-2/ currently does.

[wrandall22]

Link to my testing (I think)

[mattdrees]

Ah, well, that's annoying. I wonder why we didn't get a failure from the Unto branded checkout browser test.

[mattdrees]

AEM doesn't implement the OPTIONS method

Might be our cloudfront config; I'd find it weird for AEM to not implement OPTIONS. But the solution here is a good one, probably better.

[mattdrees]

@wrandall22 should we make a synthetic test for jf's branded checkout? I'd wager they're the largest user of that feature.

[wrandall22]

I think there is already a synthetic test for JF branded checkout here.

[wrandall22]

As for the intermittency of this error, I believe it is due to only capturing 10% of sessions. There are a few failures on the JF branded checkout test, but the retry succeeded each time (hence lack of notification).