Chore/refactor fiat rates

[AdamSchinzel]

Description

Bigger fiat rates refactor mainly to remove remaining legacy code, store historic rates from transactions to redux store and show fiat value for tokens in history.

• 58ea5b5 - Deleted rates from transactions since they are not anymore saved and retrieved from there.
• a9273b9 - Group transactions per symbol and contract and then fetch rates for timestamps, save fiat rates for timestamps to redux storage, round timestamps to hour so we make less requests (24 hours is in my and @tomasklim opinion way too much).
• 28c28c2, 5e9b807 - Show fiat value with new approach since we get rid of [fiatCurrencyCode]: Rate | undefined.
• d8e51ac - Just some docs update.
• 5092ece - Store historic fiat rates to storage.
• f5b657d - Remove + sign from day header for crypto and fiat amount if it's 0.

Related Issue

Resolve #10431
Resolve #12289

Screenshots

[matejkriz]

It does not work on my machine 🤔

---

wallet NOT remembered -

develop:

---

chore/tokens-transactions-fiat-rates:
see the zeros for ETH

---

first time I tried with wallet remembered on develop, then switch to chore/tokens-transactions-fiat-rates to see the migration in action and I got in this state (no historical fiat rates even for ETH):

[Nodonisko]

I think we should go deeper with refactor here. We should separate fiat rates and transactions as much as possible so I would prefer to not have any direct reference to specific txid.

Solution that I suggest:

1. Take transaction time round it to 24 hours for example (this will save lot of request)
2. Store it in format { [FiatRateKey]: { [timestamp: number]: Rates }} in fiat rates reducer
3. Create selector that will select this rate by timestamp + network symbol + contract
4. Use this to save also for mainnets fiat rates not only tokens, no reason to split logic here because it's basically same except contract id

This approach is IMHO much more flexible and resource savy than when we tie fiat rates to specific transactions because:

1. Fiat rates request saved (due to time rounding)
2. When user don't have wallet remembered we don't need to delete rates after disconnect and we have imidiatelly avaiable them again when device is connected (again request saved, faster for user, offline support)
3. If user have multiple transactions of same asset in one day they need just one entry

[AdamSchinzel]

I think we should go deeper with refactor here. We should separate fiat rates and transactions as much as possible so I would prefer to not have any direct reference to specific txid.

Solution that I suggest:

1. Take transaction time round it to 24 hours for example (this will save lot of request)

2. Store it in format { [FiatRateKey]: { [timestamp: number]: Rates }} in fiat rates reducer

3. Create selector that will select this rate by timestamp + network symbol + contract

4. Use this to save also for mainnets fiat rates not only tokens, no reason to split logic here because it's basically same except contract id

This approach is IMHO much more flexible and resource savy than when we tie fiat rates to specific transactions because:

1. Fiat rates request saved (due to time rounding)

2. When user don't have wallet remembered we don't need to delete rates after disconnect and we have imidiatelly avaiable them again when device is connected (again request saved, faster for user, offline support)

3. If user have multiple transactions of same asset in one day they need just one entry

👍 Agree, I also had something similar in my mind but just thought I would do it in separate PR.

[Nodonisko]

I would suggest to do it in one to avoid multiple migrations of storage

[matejkriz]

2. we don't need to delete rates after disconnect and we have imidiatelly avaiable them again when device is connected

I really like the whole idea except this one point - I certainly wouldn't leave fiat rates stored, even rounded to days, unless we inform users about it somewhere nicely...

Feel free to check it somebody else now

[matejkriz]

Please wait with merging this after suite-native freeze (hopefully today/Monday) 🙏 I'll try to look at it, but I can't promise for Today.

[Nodonisko]

Mobile and common part seems OK