Close two related silent-failure gaps in offline-db journal replay, found from
a live incident: rotate_journal.sh/daily_checkpoint.sh kept reporting success
(exit 0, no email) while never actually advancing the offline database's
journal counter.
replay_journals_to_offline_db(): when neither the plain nor gzipped form of a
numbered journal existed, the code fell through silently (no p4d -jr call, no
die()) and then unconditionally re-wrote offline_db_usable.txt anyway,
marking the offline db usable despite nothing having been replayed. Converted
to if/elif/else with the else branch calling die() -- this is a real replay
failure, not a benign condition. Applied to both replay passes (the
$CHECKPOINTS pass and the $JOURNALS pass).
gzip_mv_journals(): FIRSTJOURNALNUM was computed via the same 'sort -nr | tail
-n 2 | head -n 1' trick replay_journals_to_offline_db() uses, but without
that function's preceding 'touch prefix.jnl.0' sentinel -- so it permanently
excluded whatever the current smallest REAL journal number was (confirmed by
hand-tracing the steady-state and backlog-burst cases), leaking exactly one
uncompressed journal file per instance in journals.rotated forever. Added the
matching sentinel.
Both sentinels (here and in replay_journals_to_offline_db) are now removed
immediately after the calculation that needed them, rather than left to
persist -- a persisting "prefix.jnl.0" file would otherwise be a real,
matchable file that a later run could mistake for actual journal data if
OFFLINEJNLNUM is ever legitimately 0.