fix(generators): own backoff timing in the worker to fix ExponentialBackOff data race (PIPE-1222)

[Dylan-M]

Proposed Change

Every generator built its send loop with backoff.NewTicker(backoffConfig) and also called backoffConfig.Reset() from the worker goroutine. NewTicker runs its own goroutine that repeatedly calls NextBackOff(), so two goroutines mutated one backoff.ExponentialBackOff, which is not safe for concurrent use. That is a data race on the backoff's interval state.

This drops backoff.NewTicker and drives the interval from a time.Timer owned by the worker. Only the worker calls NextBackOff() and Reset() now, so the backoff state has a single owner. Emission cadence and the reset-on-success behavior are unchanged.

Applied to all 12 generators that shared the pattern: json, apache, apache_combined, apache_error, nginx, filegen, okta, paloalto, postgres, kubernetes, wel, winevt.

How to validate

• Automated: go test -race ./generator/... passes. Those suites were the failing signal before this change (they reported the Reset() vs NextBackOff() race under -race).
• Manual: run a generator against main and this branch (e.g. blitz --config <json config>) and confirm the output cadence is unchanged.

Checklist

• Changes are tested
• CI has passed

[Dylan-M]

• ci: run the test suite under the race detector (PIPE-1223) #272
• fix(output): drain buffered records on TCP/UDP Stop (PIPE-1230) #271
• fix(count): fix Acquire/Reset data race in Tracker (PIPE-1231) #270
• fix(generators): own backoff timing in the worker to fix ExponentialBackOff data race (PIPE-1222) #269 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.