Fix inconsistent route order test flake in TestParserSNI

[rainest]

What this PR does / why we need it:

Use a consistent order for the routes attached to a service in the parser. This makes tests that care about the route index not flaky.

Which issue this PR fixes:

TestParserSNI began failing recently, e.g. https:/Kong/kubernetes-ingress-controller/actions/runs/6407581302/job/17394681361

The origin of the flake isn't clear, but 23de4f5 seems the most likely candidate for introducing it based on date and affected code.

Special notes for your reviewer:

This is, oddly enough, the only parser test that uses multiple indices. We could alternately look up the routes by name for this test and not change anything in the translator. IDK how likely we'd be to add other affected tests in the future, or how much we'd care about the small bit of essentially wasted CPU time to avoid it.

PR Readiness Checklist:

Complete these before marking the PR as ready to review:

• the CHANGELOG.md release notes have been updated to reflect any significant (and particularly user-facing) changes introduced by this PR only fixes tests for an unreleased change

[codecov]

Codecov Report

All modified lines are covered by tests ✅

Comparison is base (27c51e5) 77.7% compared to head (e0a4a84) 77.7%.
Report is 3 commits behind head on main.

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #4777   +/-   ##
=====================================
  Coverage   77.7%   77.7%           
=====================================
  Files        163     164    +1     
  Lines      18541   18561   +20     
=====================================
+ Hits       14409   14436   +27     
+ Misses      3322    3316    -6     
+ Partials     810     809    -1     

Files	Coverage Δ
internal/dataplane/parser/translators/ingress.go	95.0% <100.0%> (+0.1%)	⬆️
internal/util/stringheap.go	100.0% <100.0%> (ø)

... and 8 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[randmonkey]

IMO it would be better to modify the unit tests (like finding the target route using lo.ContainsBy) instead of changing the parser to fix the order of routes if we do not have other reasons to have a fixed route order.

[pmalek]

I have created #4781 which changes the tests instead of the code which creates the service routes.

One thing though, which is on my mind, is that perhaps we should actually do it as proposed in here because that might reduce sending unnecessary configuration change requests to Gateway, right? If we change it in tests then more requests could be sent because the order of service routes could change from parser run to parser run even though the underlying objects didn't change.

[pmalek]

That comment might not be 100% accurate because the order ultimately does matter when we want to figure out if the config is different than the one were going to overwrite (in Admin API) right?

[czeslavo]

I believe sorting is handled in another layer - deckgen.ToDeckContent sorts all the entities:

kubernetes-ingress-controller/internal/dataplane/deckgen/generate.go

Line 38 in 1e541bb

func ToDeckContent(

I think it's okay to stick to that and leave the parser to return non-deterministically ordered slices.

[pmalek]

Cool. In that case we could add a comment mentioning this explicitly. And just leave it as it. Would this mean that we can move forward with #4781 ?

[pmalek]

Would it be difficult to make the heap contain the ingressTranslationMeta (just as in the map) to prevent having both map and heap inside the ingressTranslationIndex?

[rainest]

I tried as much and got sad discovering that this didn't really slot neatly into the simple data structure :) We have to modify the entries as we go to add new paths, and we find the correct entry to modify based on the key, so we basically end up with some combination of a map and a heap to manage that, sooooo...