feat(transaction): span_count.total

[Qard]

Fixes #552
Depends on #557

Checklist

• Implement code
• Add tests

[Qard]

One as-yet unanswered question is if span_count should be null on unsampled transactions.

[watson]

The tests fail because of #554

I don't like span_count === null when the transaction is upsampled to be honest. I know about the performance implications, but it also just feels "unclean" to send up these JSON objects containing null objects. But I'm not sure if it's just vanity or if there's something deeper 🤔

[Qard]

By that, do you mean you'd prefer the span_count is always present, or that it should be undefined?

[watson]

I mean that I prefer the JSON document not to include it for un-sampled transactions. There's a lot of optional fields in our payload that I feel would be weird if they were reported as null. But the APM Server will just ignore them (I assume), so I guess there's no technical problem in keeping it as null.

[Qard]

I think explicitly defining them as undefined should avoid the hidden-class problem the same as defining as null does. We could try that.

[Qard]

Rebased with #557 to get tests passing.

[watson]

Once the "parent" PR have been merged and this one rebased, I'm good to merge

[Qard]

Updated to reflect the current state of the decision in elastic/apm-server#1241.

[Qard]

I've also changed the dropped.total to dropped, as suggested in elastic/apm-server#1241 (comment).

[watson]

Should this PR be rebased or squashed and merged?

[Qard]

Could squash and merge, if you edit the commit title/message to describe all the changes. Rebase is fine too though.