Improvement - schema reader replay logs

[muralibasani]

About this change - What it does

• Bug fix: set_not_ready() now resets the replay-timing state (start_time, last_check, _replay_start_logged). Without this, after a master rebalance the next "Schema replay completed in X seconds" log reported time since the original process start (potentially hours), and "Starting schema replay" never re-fired. Resets happen inside _ready_lock for symmetry with the existing _ready write.

• Refactor: replaced the dual-purpose startup_previous_processed_offset (sentinel + rate-calc state) with a dedicated _replay_start_logged bool. Same intent, clearer code.

• Log accuracy: reworded "Starting schema replay: N messages to process" → "reading up to offset N", and "Schema replay completed in X seconds (processed N messages)" → "read up to offset N". On compacted topics (which _schemas always is), offsets are not record counts — the old wording mis-suggested 6.9M records were processed when only ~100 lived in the topic after compaction.

• Removed misleading metric: dropped recs/s from the DEBUG "Replay progress" line. The calculation (offset - prev_offset) / dt measures offset-position delta per second, which on compacted topics correlates with neither records nor bytes. This produced absurd numbers like "26M recs/s" because a single consumed record could jump the position by millions of offsets. The progress percentage already conveys the only meaningful signal.

• Also removes a latent divide-by-zero in the recs/s calculation that could have triggered if _is_ready ran twice within the same monotonic-clock tick (possible right after set_not_ready).

References: #xxxxx

Why this way

[github-actions]

Coverage report

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
src/karapace/core
schema_reader.py
Project Total

This report was generated by python-coverage-comment-action