Specify the expected semantics of clear APIs in tests

[teh-cmc]

It has been clear from earlier discussions that not everybody is aligned on what should be the semantics of our clear APIs.
We need to agree on those and materialize them as unit tests both as a mean of specification and to prevent regressions.

Related: the implementation of #3023 revealed some flakiness issues that should have been caught by these tests to-be.

Some examples

Assuming that we're querying for LatestAt("frame", 2): what are the expected semantics for this?

rr.set_time_sequence("frame", 1)
rr2.log("points", rr2.Points2D([[0, 0], [1, 1]]))
rr2.log("points", rr2.Clear(True))

Or this?

rr.set_time_sequence("frame", 1)
rr2.log("points", rr2.Clear(True))
rr2.log("points", rr2.Points2D([[0, 0], [1, 1]]))

What about this?

rr.set_time_sequence("frame", 1)
rr2.log("points", rr2.Points2D([[0, 0], [1, 1]]))
rr2.log("points", rr2.Clear(True))
rr2.log("points", rr2.Points2D([[0.5, 0.5], [1.5, 1.5]]))

I.e. do clear APIs follow the usual no-global-ordering/per-thread-row-id-ordering model, or do they break away from that in order to make distributed clears easier to work with?

Update: also, what about the very weird case where a row comes in that contains both ClearSettings component and a bunch of other components? For now, #3023 will make it so the ClearSettings component "wins" over everything else.

[teh-cmc]

Quoting @jleibs:

The existence of pending clear is to handle cases where data is received after the clear event, but still has a time stamp <= the clear event.

So then the most important thing to specify and test is what happens to rects in e.g.

rr.set_time_sequence("frame", 1)
rr2.log("points", rr2.Points2D([[0, 0], [1, 1]]))
rr2.log("points", rr2.Clear(True))

rr.set_time_sequence("frame", 0) # !!
rr2.log("points", rr2.Rect2D([...]))

[teh-cmc]

The behavior of (pending) clears has been fully formalized in #4144.

The only thing that hasn't been formalized is the expected behavior of intra-timestamp tie-breaks for clears (mostly useful when logging to a single entity is distributed across multiple processes and clears are involved).

Today, this implicitly follow the same behavior as any other data: RowId order defines the "winner".
I'm going to make that behavior explicit in a test, and we can decide to change it in the future if needed.

[teh-cmc]

Today, this implicitly follow the same behavior as any other data: RowId order defines the "winner". I'm going to make that behavior explicit in a test, and we can decide to change it in the future if needed.

Except the RowId in question will be the RowId generated by the cascaded clear mechanism, which as far as the end user is concerned might as well be unspecified behavior.

So no, we have no way to formalize that at the moment (other than documenting that it is in fact undefined behavior).