TS: integration with state-based replication

[feiyang3cat]

What changed?

1. Active cluster — capture time-skipping state changes for replication using timeSkippingInfoUpdated, ms.isStateDirty(), cleanupTransaction and TimeSkippingInfo.LastUpdateVersionedTransition.
2. Active & passive — idempotent timer-task regeneration

• Active: only when a skip transition was emitted this transaction.
• Passive (PartialRefresh, state-based replication): only when TimeSkippingInfo.LastUpdateVersionedTransition >= minVersionedTransition.

3. Passive cluster — time-skipping timer-task executor
   The standby's regenerated TimeSkippingTimerTask fires through executeTimeSkippingTimerTask. If the associated FastForwardInfo is still the active, the standby awaits the replicated transition rather than driving it.

Why?

the goal is to make sure time skipping works correctly during failovers with state-based replication

How did you test it?

• built
• run locally and tested manually
• covered by existing tests
• added new unit test(s)
• added new functional test(s)

[feiyang3cat]

Question for CGS team:

Not sure if in complicated failover cases (A failover to a slow B and then A is up again as stand-by) there may be legacy timer tasks that have larger event IDs than the one of the current mutable state but even this happens loadMutableStateForTimerTask will filter these tasks and they will never reach executeTimeSkippingTimerTask

	// Validation based on eventID is not good enough as certain operation does not generate events.
	// For example, scheduling transient workflow task, or starting activities that have retry policy.
	//
	// Some tasks don't have an associated eventID (CHASM tasks).
	eventID, eidOk := getEventID(task)
	if !eidOk || eventID < mutableState.GetNextEventID() {
		return mutableState, nil
	}

already added time skipping timer task logic to getEventID in previous PRs

[yux0]

can the source event ID in the skipping info > timer task event ID? Does it mean the timer task is invalid?

[feiyang3cat]

1. yes, it can. if the user sets a new duration limit later, the event ID may be different, and the old timer shall be acked silently so I returned nil, nil for this case. does this make sense? another way is to find the overwritten source event ID in events or keep them in a list in the mutable state, and I was not sure what is the benefits so I used the current simple logic

2. under current replication mechanism, will it happen under extreme edgy case

• active A (like next event ID = 10), passive B (catching up to 5)
• failover -> B as active (like next event ID = 5, and A as passive so A use next ID = 5 again
• failover back to-> A as active and proceed to event ID = 10 with a new timer, and an older timer when A was active in the first place fired to match the "event ID 10" but totally a different history branch?

[feiyang3cat]

refresh doesn't follow idempotency so that tasks shall be regenerated when lost