Arrays in HTTP API responses are not sorted

[victorb]

Somewhat annoying but minor issue.

When making API requests to ipfs-cluster, it seems that the response sometimes changes the order of the arrays. So the first request returns {"peers": ["A", "B"]} and the second one could return {"peers": ["B", "A"]} randomly. This is a bit annoying since responses are harder to cache, since the ordering in arrays are important.

Sorting the arrays before letting the HTTP endpoint respond, would solve this issue.

The endpoints I've found so far not properly sorting before responding:

Endpoint	Attributes(s) not sorted
/id	addresses, cluster_peers_addresses and ipfs.addresses
/allocations	Response is non-sorted array
/peers	Each peer has the same response from /id so needs sorting on the same attributes

I'm sure I missed others, but I've not used all API endpoints.

[hsanjuan]

Some things might be worth sorting in the ToSerial() methods in api/types.go for convenience.

I don't think we'll sort Allocations, as that can grow significantly to the point it might affect performance.

[hsanjuan]

One other thing that should be sorted is the map of peers in PinInfo when printed. We don't have ToSerial() methods anymore though, so this would be purely an ipfs-cluster-ctl thing.

[kishansagathiya]

I am assuming that there number of pins will be much more than number of peers. So, I see only two outputs that we can sort without affecting performance.

At API level:
[]*api.ID could be sorted by peers for peer listing (GET /peers)
[]api.Metric could be sorted by peers

[hsanjuan]

See if you can find why peers ls or status comes out unsorted at all. You probably arrive to Peers() giving an unsorted list of peers so that the responses to the broadcast request to those peers are in different order everytime. And this might come to the monitor giving metrics in different order on crdts.

Also worth sorting the addresses as mentioned at the top.