fix: remove localeCompare from account order sorting

[cassapula]

Problem

localeCompare should be limited and not used when not required. For the sorting of the account metas, we don't specifically require the usage of it since those are Public Keys, and a direct comparison would work as expected.

This is prone to issues in react native, depending on the JS engine being used.

Context: Conversation on the #21724.

Summary of Changes

This fix makes the sorting of account metas work predictably independent of the JS engine used, as localeCompare behaves differently depending on the JS engine (v8 vs JSC, for example).

[jordaaash]

Not using localCompare maybe makes sense, but I think the implementation here has issues.

[jordaaash]

Why lowercase? This will change the sort order. It will also cause two pubkeys which are not identical to be interpreted as identical. Does that matter?

[jordaaash]

Hmm. Using < and > doesn't seem right. The string may start with a number, causing it to be parsed as a number and then compared with another string (that may not start with a number).

From https://www.w3schools.com/js/js_comparisons.asp

When comparing a string with a number, JavaScript will convert the string to a number when doing the comparison. An empty string converts to 0. A non-numeric string converts to NaN which is always false.

Is this desired behavior?

[steveluscher]

I remember bringing this up when we made the last change to this code as seeming off (what locale could possibly affect the order materially) but we never ended up pulling on the thread.

[steveluscher]

Also, I'm curious to know the details of the different behavior on RN. What engine? What strings produce different orders?

[steveluscher]

To fix the RN mismatch: did we consider figuring out what the difference was and being explicit in our call to localeCompare (ie. supplying both a hard-coded locale, and a static set of Intl.Collator options)