Refactor scrape_task_producer to use event_queue Kafka producer

[extreme4all]

Motivation

• Replace direct kafka producer/consumer usage in the scrape task producer with the shared event_queue abstraction for consistency and easier backend swapping.
• Simplify the fetch parameter state machine and daily reset logic to improve readability and maintainability.
• Batch and centralize queueing logic to reduce per-message operations and surface producer errors explicitly.

Description

• Updated bases/bot_detector/scrape_task_producer/core.py to use QueueFactory.create_queue(...) and a QueueProducer[ToScrapeStruct] instead of the previous PlayersToScrapeProducer/consumer pair.
• Reworked FetchParams to add _update_step_flags, set_step, reset_for_new_day, and a stronger update_date signature to centralize and simplify step flag management and date calculations.
• Replaced the per-message produce_one loop with a batched player_producer.put(...) call that constructs ToScrapeStruct messages and raises on backend errors.
• Removed use of the consumer lag check and consumer startup/stop since the producer-only flow is used now, and centralized Kafka config creation using KafkaConfig and KafkaProducerConfig from the event_queue adapters.

Testing

• No automated tests were executed as part of this change (no uv run pytest was run).

---

Codex Task

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 704423dfb6

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Handle QueueProducer.put error propagation

The new error handling around player_producer.put(...) never triggers because QueueProducer.put doesn’t return the backend’s Exception (it awaits and returns None). In practice, adapter errors like ProducerNotStartedError or KafkaTimeoutError will be silently ignored here, so enqueue failures won’t be surfaced or logged as intended. Consider propagating the adapter’s return value (or raising inside the adapter) so this check can actually detect failures.

Useful? React with 👍 / 👎.