Fix APM tracer to respect recording status of spans

[mosche]

This fixes a bug in APM tracer that ignored the recording status (isRecording) of spans as decided by the APM Java agent.
This circumvented transaction_max_spans and resulted in a chain of descendent spans in a transaction being held in memory potentially causing OOMs for very long running transactions.

This PR fixes the tracer to properly respect isRecording.

1. APMTracer receives the parent task's trace context and sets that as the parent of a new span.

            final Context parentContext = getParentContext(traceContext);
                spanBuilder.setParent(parentContext);

2. APMTracer requests a new span, setting the start time to the same as the transaction start time

            Instant startTime = traceContext.getTransient(Task.TRACE_START_TIME);
                spanBuilder.setStartTimestamp(startTime);
            final Span span = spanBuilder.startSpan();

3. The span is created but is too many for the transaction because transaction_max_spans is exceeded for this span, so it is set as a non-recording span
4. APMTracer stores the Context containing the span in its spans map, ie this new span is now the next parent span so will be stored as the task's trace context

• this is incorrect because the span is a non-recording span, so should be discarded
• the result of the incorrect approach is that you can have a chain of descendent spans in a transaction which can be unlimited in size, and all with the same start time

(Replaces #136978)

[elasticsearchmachine]

Pinging @elastic/es-core-infra (Team:Core/Infra)

[rjernst]

LGTM

[elasticsearchmachine]

💚 Backport successful

Status	Branch	Result
✅	9.2
✅	8.19
✅	9.1