chore(safego): remove unused WithRestartTimeout (fixes data race)

[kotwal-itpro]

Problem

Execution.WithRestartTimeout mutates exec.restartTimeout from the caller's goroutine, while the spawned goroutine's panic-recovery defer reads that same field on restart. When a caller uses the documented RunWithRestart(f).WithRestartTimeout(t) builder pattern (as safego's own TestHandlePanicAndRestart did), the goroutine is already running by the time the setter fires — any panic in the interim races the write.

go test -race ./bulker/jitsubase/safego/ reproduces it deterministically on current newjitsu:

==================
WARNING: DATA RACE
Read at 0x... by goroutine 9:
  github.com/jitsucom/bulker/jitsubase/safego.(*Execution).run.func1.1()
      bulker/jitsubase/safego/safego.go:56 +0x70
  runtime.gopanic()
      runtime/panic.go:860 +0x128
  github.com/jitsucom/bulker/jitsubase/safego.(*Execution).run.func1()
      bulker/jitsubase/safego/safego.go:62 +0x78

Previous write at 0x... by goroutine 8:
  github.com/jitsucom/bulker/jitsubase/safego.(*Execution).WithRestartTimeout()
      bulker/jitsubase/safego/safego.go:68 +0x19c
  github.com/jitsucom/bulker/jitsubase/safego.TestHandlePanicAndRestart()
      bulker/jitsubase/safego/safego_test.go:24 +0x198
==================
    testing.go:1712: race detected during execution of test
--- FAIL: TestHandlePanicAndRestart (0.30s)
FAIL	github.com/jitsucom/bulker/jitsubase/safego	0.669s

safego.RunWithRestart / safego.Run are called in 20+ production paths across bulker/, ingest/, kafkabase/, sync-controller/, bulkerapp/, eventslog/, and jitsubase/, so the primitive is load-bearing. No current production caller happens to chain WithRestartTimeout, so the race does not fire in shipped code — but the pattern is publicly exported and documented, so any future caller (or a copy-paste from the existing test) trips it.

Fix (backward compatible)

1. New constructor RunWithRestartTimeout(f func(), timeout time.Duration) *Execution — sets the timeout before the goroutine spawns, eliminating the need for the mutating builder pattern in the common case.
2. run() captures restartTimeout into a function-local at spawn time, so a subsequent mutation via the deprecated setter (or any future mutation of the shared Execution) cannot race the goroutine's recovery handler.
3. WithRestartTimeout retained for source-level backward compatibility and marked with a Deprecated: doc comment pointing callers at the race-free constructor.

Test

Updates TestHandlePanicAndRestart to use the new constructor and an atomic.Int32 counter (the previous plain-int shared counter was itself flagged by -race).

Verified

• go test -race -count=5 ./bulker/jitsubase/safego/ — 5/5 pass (was consistently failing before)
• go build ./... clean on jitsubase, kafkabase, bulkerlib, bulkerapp, ingest, sync-controller
• No breaking API changes: Run, RunWithRestart, and WithRestartTimeout all keep their signatures; new RunWithRestartTimeout is additive

[kotwal-itpro]

Hey team, just checking in on this one — rebased against latest newjitsu today (was quite a way behind since safego hadn't been touched upstream). CI should re-run.

The fix captures restartTimeout at spawn time to eliminate the data race in WithRestartTimeout. safego is called in 20+ production paths across bulker, ingest, kafkabase, sync-controller, bulkerapp, and eventslog, so it seemed worth getting right. Happy to change the approach if you'd prefer a different sync primitive.

Thanks!

[kotwal-itpro]

Rebased onto latest newjitsu to keep this current and mergeable (had drifted since the last sync). No changes to the fix itself — diff is identical, just replayed cleanly on top of recent upstream changes. CI should re-run on the new head.

[kotwal-itpro]

@absorbb @sahiltyagi-jitsu — would one of you have a few minutes to take a look at this? It's a small, self-contained fix (2 files in bulker/jitsubase/safego) for a data race in WithRestartTimeout: the restart timeout is now captured at spawn time instead of being read concurrently from the restarting goroutine. go test -race on the package passes.

I've rebased onto the latest newjitsu. CI hasn't run on this PR yet, presumably because it needs maintainer approval for a fork contribution, so approving the workflow run would be much appreciated. Happy to adjust anything. Thanks!

[absorbb]

@kotwal-itpro
i guess there is no need to keep WithRestartTimeout - it is not used anywhere

[kotwal-itpro]

@absorbb good call, thanks. I've updated the PR to simply remove WithRestartTimeout: with no way to change restartTimeout after the goroutine starts, the race goes away with it. The test now builds the Execution directly with a 50ms restart timeout and uses an atomic counter, so go test -race passes. Net change: -5 lines in safego.go plus the test update.