Fix flaky TestManagedRegistry_externalLabels

[LasseHels]

What this PR does:
This pull request implements a solution to the flaky TestManagedRegistry_externalLabels test.

TestManagedRegistry_externalLabels is flaky since it relies on a specific label order which is not guaranteed. The solution is particularly tricky as neither sample order nor label order is guaranteed across the test suite, meaning collectRegistryMetricsAndAssert must assert agnostic of both sample and label order.

This pull request contains no functional changes to Tempo.

Which issue(s) this PR fixes:
Fixes #2881.

Checklist

• Tests updated
• Documentation added
• CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]

[joe-elliott]

This one has plagued us for awhile, but I've never had time to look at it.

One thing that might make it cleaner would be to sort by timestamp first? then at least you could compare expectedSamples[i] vs actualSamples[i]?

[LasseHels]

One thing that might make it cleaner would be to sort by timestamp first? then at least you could compare expectedSamples[i] vs actualSamples[i]?

Good idea!

Action taken: instead of my clumsy nested loop, we now prefer a much cleaner implementation of sorting both slices, and then asserting equality on expected[i] and actual[i].

Sorting by timestamp was not sufficient, as samples can have identical timestamps. I'm using sample.String() to sort. This is probably fine, but means that the tests now have an implicit dependency on the String() method of sample; changing the String() method risks breaking the tests. I think I'm OK with this, as the alternative is a more complicated test, which is also not ideal.

[joe-elliott]

lgtm. thanks for the test fix!