Sidekiq integration for error tracking #344

Problem Statement

We run posthog-rails 3.20 next to sentry-sidekiq on a Rails 8.1 + Sidekiq 7 app. Sidekiq job errors reach PostHog through the Rails error reporter. That works, but it gives a worse result than a dedicated integration can produce:

1. The issue is named after Sidekiq wrapper, not the real error
   When a job goes through Sidekiq retry handler, the exception (reported to Rails.error) is Sidekiq::JobRetry::Handled, and the real error is only its cause. In the last few days we had multiple similar cases, e.g. Handled wrapping PartnerApps::APIError (an embedded partner app errors inside our app). Exclusions and grouping also see the wrapper first (fix(rails): match excluded exceptions on subclasses and cause chain #331 fixes the exclusion side btw).

2. Every retry is a separate event
   There is no way to report only the final attempt or only dead jobs. One rate-limited job class produced about 35k Sidekiq::Limiter::OverLimit retry events in 6 hours.

3. Job context is thin
   The only job property on the event is $context_sidekiq_job_class. No queue, jid, retry count or (filtered) arguments, so we can't easily a first attempt from a final one or find the job in Sidekiq UI.

4. Errors outside a job are not captured
   Sidekiq own failures (Redis connection errors, fetch, scheduler errors) go to Sidekiq.error_handlers, which posthog-rails doesn't register. There is also no way to turn off the Rails error reporter subscriber on its own while keeping the rest of the integration. Replacing it with a custom handler seems awkward.

Solution Brainstorm

A Sidekiq integration opt-in like auto_instrument_active_job along the lines of sentry-sidekiq:

• Sidekiq server middleware (or error_handlers entry) that reports the original exception, not Handled, and skips the duplicate report from Rails.error.
• Job context of the event: queue, jid, job class, retry count, arguments passed through the existing parameter filter.
• An option to report only when retries are exhausted, plus a separate option for dead jobs.
• An error_handlers entry for errors raised outside a job.
• A config.report_rails_errors = false style switch for the subscriber.

If we agree on option names (and a general concept) - I could prep a PR.