Should we get rid of the RateEncodingFactor scheme in favor of one based on big?

[buck54321]

The current scheme for encoding exchange rates for a trade is to find an atomic unit that works such that exchange rates can be encoded as an integer (the message rate) via use of a RateEncodingFactor = 1e8. For example, trading 100 atoms of base asset DCR for 10 atoms of quote asset BTC, would give a message rate of 10 / 100 * 1e8 = 1e7. This mitigates floating-point error that might accumulate during encoding and decoding to and from msgjson types. But this scheme has some limitations. We've already seen this in our EVM assets, where we can't use the real atomic unit, 1 Wei = 1e-18 ETH, and instead we have to use our own "atomic unit" 1 Gwei = 1e-9 ETH. This actually creates a lot of headaches for us as we have to carefully handle conversions in our wallet and server backend packages.

So... Should we switch to another scheme? I think the obvious one is to use big types in Go, and encode to string in JSON.

This change would echo through everything. It's not trivial. But if it's the right move, I think we should. Thoughts?

[norwnd]

Thoughts:

• it's not entirely clear to me whether it's worth it switching to another approach at this point, it's probably gonna create lots of code-conflicts (and potentially fresh bugs) - so unless it's really blocking something I would postpone such refactoring until most other development is finished and slowed down
• the approach with big int is probably the correct choice at least on back-end, but I'm not sure what corresponding JS primitive can be used (if we keep using floating-point JS Number with larger values it might only bring more floating point errors in UI); An alternative approach some people go for is proper Decimal representation (such as https://github.com/cockroachdb/apd) - but it's likely overkill here, and it's not as CPU/memory efficient I guess
• in UI the min number of 1e-9 is probably fine for things like Gwei (or Lamports for Solana), I haven't and don't see much benefit for providing higher granularity (at least in UI) - just round things down and that's probably sufficient for all use-cases
• somewhat related side-note, UX-wise many quantities/amounts/rates you can see in UI currently have too much decimals - we could cut some of them off (eg. for BTC-USDT pair you don't really need a rate-step of 0.000001 or whatever it is, it's probably fine to have 0.01 or even just 1)