Flush telemetry in a detached subprocess

[carole-lavillonniere]

Motivation

lstk aws took ~2x as long as awslocal for simple calls (~1.6s vs ~0.75s). The overhead came from telemetry.Client.Close() blocking on HTTP POSTs to the analytics endpoint before process exit (~900ms confirmed via LOCALSTACK_DISABLE_EVENTS=1). As discussed on the ticket, the flush now happens in a detached subprocess after the CLI returns, so analytics latency no longer affects command responsiveness.

Changes

• telemetry.Client buffers events in memory; Close() hands them to a detached subprocess and returns immediately instead of draining HTTP requests
  • The buffer is capped at 64 events (pendingCap) as a safety bound — a single CLI run emits only 1–3 events in practice. On overflow the oldest event is dropped, keeping the most valuable one: the final lstk_command event emitted after the command completes. (The previous channel-based implementation had the same cap but dropped the newest event on overflow.)
• New __flush-telemetry mode reads JSON-line events from stdin and POSTs them, bounded by a 10s wall-clock cap so orphaned flushers can't linger
  • It is short-circuited at the top of Execute(), before logger/keyring/telemetry/cobra init: the flusher writes nothing to the filesystem (no lstk.log, no config dir creation — which raced with test temp-home cleanup on macOS)
• Platform-specific detach: Setsid on Unix, windows.DETACHED_PROCESS | windows.CREATE_NEW_PROCESS_GROUP (via golang.org/x/sys) on Windows
• Trace context is propagated to the flusher via TRACEPARENT/TRACESTATE env vars, so its telemetry flush and telemetry POST spans join the originating command's trace
• The flusher never constructs a telemetry client or cobra command, so it structurally cannot emit events about itself or spawn another flusher recursively

Tests

• TestStartCommand_DoesNotBlockOnSlowAnalyticsEndpoint: parent exits in <1s while the endpoint hangs 3s, and the event is still delivered
• TestCommandTelemetryIsDeliveredByDetachedFlusher: Docker-free end-to-end flush — also runs on Windows CI, covering the Windows detach flags (the Docker-based telemetry tests skip there)
• TestFlushTelemetrySubcommandDoesNotSpawnRecursively: guards against recursive flusher spawning
• TestOtelFlushSpansJoinCommandTrace: flush spans from the subprocess reach the OTLP collector
• Unit tests for event buffering/handoff (including cap/drop-oldest behavior) and the TRACEPARENT round-trip (trace/span ID equality)
• Manually verified in Jaeger: telemetry flush appears as CHILD_OF the command span in a single trace; lstk aws sts get-caller-identity-style commands no longer wait on analytics

Closes FLC-648

Tracing

The fact that the telemetry event is emitted after the main command's process returned is clearly visible on this trace:

[anisaoshafi]

Thanks for tackling this and the thorough testing and PR description🥇