Jaeger exporter still creates too big UDP packets

[Jownathan]

Description

This bug report is similar to a previous bug report, this bug was fixed in this PR but the issue remains, potentially because of a small mistake in the PR.

The original bug was:

Jaeger exporter logs errors like these: 'data does not fit within one UDP packet; size 65006, max 65000, spans 440'. This leads to spans missing from our traces.

But after the PR the bug still occurs and the logs now look as follows:

'data does not fit within one UDP packet; size 64941, max 64930, spans 435'

As you can see, the max went from 65000 to 64930. This is because of the new emitBatchOverhead of 70 introduced in the PR.
It seems that the emitBatchOverhead variable is not only used for limiting the amount of spans that get added (which is what was required to fix the original issue) but it is also used for the maximum size of an UDP packet (which is incorrect).
As seen in the error message max 64930 should be max 65000, which would fix the issue.

Environment

• OS: alpine base image
• Architecture: x86
• Go Version: 1.17
• opentelemetry-go versions:
  go.opentelemetry.io/otel v1.3.1-0.20220104180153-776bfdcb2358
  go.opentelemetry.io/otel/exporters/jaeger v1.3.1-0.20220104180153-776bfdcb2358
  go.opentelemetry.io/otel/trace v1.3.1-0.20220104180153-776bfdcb2358

Steps To Reproduce

1. Produce traces with a thousand spans.
2. Error 'data does not fit within one UDP packet; size 64941, max 64930, spans 435' is logged occasionally.

Expected behavior

Jaeger exporter does not create UDP packets that are too big.

[jflipts]

This fix seems to have resolved the issue, thank you!