Make Topk aggregate tests deterministic

[mustafasrepo]

Which issue does this PR close?

Closes #8845.

Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

[avantgardnerio]

It doesn't test the code path with collisions anymore, but that might be okay @alamb

[comphead]

Thanks @mustafasrepo but just for curiosity, how the test becomes deterministic if only test result has changed? 🤔 no extra sorting or code change

[alamb]

I think this PR makes a lot of sense to me -- thank you @mustafasrepo . I am pretty sure it still covers the core use case -- I left a comment that might also increase coverage.

@avantgardnerio if you have additional suggestions on how to improve this test that would be most helpful

[alamb]

Maybe add some rows with a duplicate timestamp to address @avantgardnerio 's comment?

Perhaps something lke

('c', 4, 10),
('c', 2, 10),

[mustafasrepo]

Thanks @mustafasrepo but just for curiosity, how the test becomes deterministic if only test result has changed? 🤔 no extra sorting or code change

In this PR, I have changed source table such that timestamp values are unique. Since each group consists of distinct rows, MIN(timestamp), or MAX(timestamp) would produce unique results after aggregation (e.g different for each row). Hence when ordering ORDER BY MIN(timestamp) is applied there is no tie break (in tie break there will be more than 1 true result, and results may change when some implementation change seemingly unrelated).