Initially, all span initial resolved timestamps are kept as zero upon resuming a
job since initial resolved timestamps are set as initial high water which
remains zero until initial scan is completed. However, since
afb95b1,
we began reloading checkpoint timestamps instead of setting them all to zero at
the start. In PR #102717, we introduced a mechanism to reduce message duplicates
by re-loading job progress upon resuming which largely increased the likelihood
of this bug. This could result in dropping events since we now sometimes make a
new frontier with all spans forwarded to initialResolved

. These errors could lead to incorrect frontier and missing events
during initial scans.

Jira issue: CRDB-38432