ddtrace/tracer: Always count dropped p0 traces and spans

[ajgajg1134]

Fixes an issue where if using client side stats not all dropped p0 traces and spans would be counted.
Note this PR is against the release-v1.41.x branch so it can be released as a hotfix for v1.41

[katiehockman]

I played around with this a bit just to understand the logic better. What do you think about something like this? Do you find it more readable / less error-prone?

func (t *tracer) sampleFinishedTrace(info *finishedTrace) {
	if info.decision == decisionKeep {
		return
	}
	var kept []*span
	if t.rulesSampling.HasSpanRules() {
		// Apply sampling rules to individual spans in the trace.
		for _, span := range info.spans {
			if t.rulesSampling.SampleSpan(span) {
				kept = append(kept, span)
			}
		}
		if len(kept) > 0 && len(kept) < len(info.spans) {
			// Some spans in the trace were kept, so a partial trace will be sent.
			atomic.AddUint64(&t.partialTraces, 1)
		}
	}
	if len(kept) == 0 {
		atomic.AddUint64(&t.droppedP0Traces, 1)
	}
	atomic.AddUint64(&t.droppedP0Spans, uint64(len(info.spans)-len(kept)))
	info.spans = kept
}

I also think there might be a bug. atomic.AddUint64(&t.partialTraces, 1) will be called today if len(kept) == 0, but isn't it possible that every span is kept, s.t. we keep the entire trace, even when applying the single span sampling rules? In that case, we aren't sending a partial trace, but a whole trace.

[ajgajg1134]

Hmm that's a good point. I'm not sure if all the spans arriving to the backend but as "single span ingested" affects the way they're displayed or how hit metrics are calculated such that even though all the spans arrived it's not really a trace since they're marked specially as "single span ingested"?

[katiehockman]

I'm not sure either. If you want to just remove that && len(kept) < len(info.spans) for now and re-introduce it later after we've looked at it we can. But I assume for this patch it doesn't make a difference since no one is using single span rules today anyway.

[katiehockman]

We should do these same checks for the single spans code too. Since no one is using it, it's fine if we do that in a follow-up PR though.