node: Make iteration over Governor information more efficient

[johnsaigle]

Description and context

In the context of the Governor, we normally we work with chainEntrys via the chains map which maps chain IDs to pointers to chainEntrys. This is nice because we can look up info by chain entry.

#4016 adds a slice of sorted chain IDs chainIds as a field to the Governor struct. The idea is to provide a stable way to iterate over chainEntry in a deterministic way. (Note that iterating over maps is non-deterministic in Go).

This works just fine but is possibly inefficient. Is there a better way to do this?

Possible approaches

Store a slice of pointers to chainEntrys

@bruce-riley recommended that we could modify chainIds to a slice of pointers to chainEntrys. If we do this, we avoid the need to store the chainIds in a slice and can simply iterate over the pointers. This may be more efficient than iterating over a slice of chainIds and then doing a map lookup for each one.

Pros: likely more efficient
Cons: A developer needs to carefully manage the slice and the map in this case instead one of the pointers is modified. (not the data that the pointer is pointing too). There is no mechanism that ensures they stay in sync.

Make use of iterators in Go 1.23

In August Go will have support for iterators. We could use this to iterate over sorted keys:

https://pkg.go.dev/iter#hdr-Standard_Library_Usage

for _, key := range slices.Sorted(maps.Keys(m)) {
	...
}

Pros: no need to store a second, redundant data structure to get deterministic iteration ordering. No desync risk. Easy to reason about.
Cons: may not be more efficient in terms of execution. Need to wait until the Guardians support Go 1.23

Definition of done

• Iterate on both approaches and possibly others
• Measure performance of potential approaches
• Evaluate performance gains against potential for mistakes
• Decide whether to replace existing implementation or replace it with a new one