Optimize SpanBuilderSdk link memory

[jkwatson]

resolves #709

[codecov-io]

Codecov Report

Merging #753 into master will decrease coverage by 0.05%.
The diff coverage is 100%.

@@             Coverage Diff              @@
##             master     #753      +/-   ##
============================================
- Coverage     78.84%   78.79%   -0.06%     
+ Complexity      761      759       -2     
============================================
  Files            98       98              
  Lines          2709     2711       +2     
  Branches        255      256       +1     
============================================
  Hits           2136     2136              
- Misses          473      474       +1     
- Partials        100      101       +1

Impacted Files	Coverage Δ	Complexity Δ
...main/java/io/opentelemetry/sdk/trace/SpanData.java	100% <100%> (ø)	2 <0> (ø)	⬇️
...ava/io/opentelemetry/sdk/trace/SpanBuilderSdk.java	93.75% <100%> (-0.07%)	34 <0> (-1)
...ntelemetry/sdk/trace/RecordEventsReadableSpan.java	90.24% <0%> (-1.22%)	43% <0%> (-1%)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5517dcb...cf86f36. Read the comment docs.

[carlosalberto]

This looks fine to me - and while on that subject, I've long wondered if we should keep the same behavior we have with Attributes, dropping the eldest entry once we have reached the maximum allowed count.

Maybe @bogdandrutu remembers about this, since we are using OC based code? ;)

[jkwatson]

Do you know why we would drop the "eldest" entry, rather than just dropping any that exceed the maximum? Is there a reason why recency would mean more relevance?

[bogdandrutu]

It is better to drop the earliest in general.

[jkwatson]

Can you explain why? Are later links somehow better than earlier ones? What's the business rationale here? [the code is much more efficient if we can just drop the later ones]