Function mz_txn_wal::operator::txns_progress_source_global

fn txns_progress_source_global<K, V, T, D, P, C, G>(
    scope: G,
    name: &str,
    ctx: TxnsContext,
    client: impl Future<Output = PersistClient> + 'static,
    txns_id: ShardId,
    data_id: ShardId,
    as_of: T,
    data_key_schema: Arc<K::Schema>,
    data_val_schema: Arc<V::Schema>,
    unique_id: u64,
) -> (Stream<G, DataRemapEntry<T>>, PressOnDropButton)
where
    K: Debug + Codec + Send + Sync,
    V: Debug + Codec + Send + Sync,
    T: Timestamp + Lattice + TotalOrder + StepForward + Codec64 + Sync,
    D: Debug + Data + Semigroup + Ord + Codec64 + Send + Sync,
    P: Debug + Data,
    C: TxnsCodec + 'static,
    G: Scope<Timestamp = T>,

TODO: I’d much prefer the communication protocol between the two operators to be exactly remap as defined in the reclocking design doc. However, we can’t quite recover exactly the information necessary to construct that at the moment. Seems worth doing, but in the meantime, intentionally make this look fairly different (Stream of DataRemapEntry instead of Collection<FromTime>) to hopefully minimize confusion. As a performance optimization, we only re-emit this when the physical upper has changed, which means that the frontier of the Stream<DataRemapEntry<T>> indicates updates to the logical_upper of the most recent DataRemapEntry (i.e. the one with the largest physical_upper).