Let SidekiqReporter publish zero for required-but-empty queues

[bjonord]

SidekiqReporter iterates Sidekiq::Queue.all, so a queue that has never been enqueued on a given shard is silently absent from CloudWatch. When that queue has a per-queue target-tracking autoscaling policy, its scale-in alarm sits permanently in INSUFFICIENT_DATA and the whole ECS service stops scaling in.

What does this PR do?

• Adds an optional required_queues: kwarg to SidekiqReporter.enable. Defaults to [], so existing consumers behave exactly as before.
• Collector now iterates (required_queues + Sidekiq::Queue.all.keys).uniq and emits 0 for any required_queues entry not present in Redis. paused? behavior is preserved for live queues.
• Bumps to 0.3.0 (additive public API change).

Note

Consumer-side change for the Teamtailor monorepo: bump the gem and pass required_queues: QUEUES_WITH_AUTOSCALING_POLICY from config/initializers/03_sidekiq.rb. Follow-up PR.

📖 Description for AI review

Context

ECS Fargate Sidekiq services on Teamtailor autoscale via per-queue CloudWatch target-tracking policies on the custom metric sidekiq_queue_latency (namespace Teamtailor/queue_times). Each queue has its own latency target (critical 1s, default 30s, import/low/mailers_low/within_1_hour/within_3_hours 300s, etc.).

AWS target-tracking only scales in when every policy can confirm it's safe. Verified on eu-cyan-sidekiq-main (2026-06-22): the publisher emitted 13 queues but never within_3_hours (that shard never enqueues to it), so its scale-in alarm sat in INSUFFICIENT_DATA and the service ratcheted from 1 to 5 tasks over weeks with zero scale-in events between spikes. Roughly $800/mo in waste across low-traffic shards.

What was added

• required_queues: kwarg on SidekiqReporter.enable. The collector lambda closes over it and passes it through to collect_metrics.
• collect_metrics(required_queues = []): keeps zero-arg backwards compatibility, walks the dedup'd union of required_queues and Sidekiq::Queue.all, defaulting absent queues to 0. Preserves the existing paused? ? 0 : latency rule for live queues.
• Spec coverage: existing zero-arg tests preserved; new tests cover the required-queue plumbing through .enable, missing-queue zero emission, and dedup when a required queue is also live.

What was intentionally left out

• The canonical queue list itself stays out of the gem. It's deployment-specific (which queues have policies depends on the infrastructure config), so passing it in from the consumer keeps the gem decoupled.
• No CHANGELOG.md entry (none exists in this repo today).

Key constraints to verify

• Calling .enable without required_queues: must behave exactly as in 0.2.0. The default [] plus the dedup'd union ensures this.
• The minor-version bump (0.2.0 to 0.3.0) reflects the new public kwarg without breaking the old surface.