fix(n1-api-calls): Omit span URL subdomain from fingerprinting

[gggritso]

Closes PERF-1937. Sometimes we get spans with URLs like "http://<client>.service.io/resource" in them. The <client> is a hard-to-parameterize string of some kind. This causes a fingerprint explosion if different transactions are getting data from different clients.

Omit the subdomain from fingerprinting (but leave detection alone). For fingerprinting, we actually want to ignore this, and only fingerprint on the path. There's basically no scenario where an application would use the same path structure from different domains and it's not an error.

[DominikB2014]

A test case would probably be good to add here.

[gggritso]

Yeah I should write some fingerprinting tests, I just haven't figured out a good way to do it yet. For N+1 API we need 10 or more spans, and they're hard to construct 🤔 I have a Jira task to increase coverage, though, so I'll do that soon!

[k-fish]

@gggritso I think the fingerprinting probably needs the most coverage since it has some permutations, doesn't create_span from event_generators do the trick for making more spans? (using the SpanBuilder?)

[DominikB2014]

Yeah I should write some fingerprinting tests, I just haven't figured out a good way to do it yet. For N+1 API we need 10 or more spans, and they're hard to construct 🤔 I have a Jira task to increase coverage, though, so I'll do that soon!

Hmm, not sure how to solve the spans being hard to construct, i've just been using create_span like @k-fish mentioned. But for fingerprint tests in general, I found it helpful not to test a single fingerprint, but to test that things get grouped correctly (aka 2 or more events have matching fingerprints),

[gggritso]

Added test coverage in #43732 for the sake of accuracy

[gggritso]

@DominikB2014 @k-fish merged my test coverage PR, so now this PR includes a test 👍🏻

[DominikB2014]

lgtm!