SyncTimestamp might be skipped unexpectedly

[JmPotato]

Bug Report

#7031 introduced a new path to skip SyncTimestamp in some cases, which might be triggered unexpectedly. For example, if it's the first time that a timestampOracle is created, both last and lastSavedTime could be zero and cause the sync to return early.

pd/pkg/tso/tso.go

Lines 158 to 175 in 301b917

	func (t *timestampOracle) SyncTimestamp(leadership *election.Leadership) error {
	t.metrics.syncEvent.Inc()
	failpoint.Inject("delaySyncTimestamp", func() {
	time.Sleep(time.Second)
	})
	last, err := t.storage.LoadTimestamp(t.tsPath)
	if err != nil {
	return err
	}
	lastSavedTime := t.getLastSavedTime()
	// If `lastSavedTime` is not zero, it means that the `timestampOracle` has already been initialized
	// before, so we could safely skip the sync if `lastSavedTime` is equal to `last`.
	if lastSavedTime != typeutil.ZeroTime && typeutil.SubRealTimeByWallClock(lastSavedTime, last) == 0 {
	t.metrics.skipSyncEvent.Inc()
	return nil
	}