feat(wallet): Apply persistent token/account balance for the rest of the wallet

[nuo-xu]

Resolves brave/brave-browser#36764
brave/brave-browser#36693
Wallet has now cached account/token balance since brave/brave-browser#35986
But only Portfolio/Assets is reading the cached balance.
This PR make the rest of the wallet first checking cached value and will fetch via core api if there is none cached balance.

Submitter Checklist:

• I confirm that no security/privacy review is needed and no other type of reviews are needed, or that I have requested them
• There is a ticket for my issue
• Used Github auto-closing keywords in the PR description above
• Wrote a good PR/commit description
• Squashed any review feedback or "fixup" commits before merge, so that history is a record of what happened in the repo, not your PR
• Added appropriate labels (QA/Yes or QA/No; release-notes/include or release-notes/exclude; OS/...) to the associated issue
• Checked the PR locally:
  • npm run test -- brave_browser_tests, npm run test -- brave_unit_tests wiki
  • npm run presubmit wiki, npm run gn_check, npm run tslint
• Ran git rebase master (if needed)

Reviewer Checklist:

• A security review is not needed, or a link to one is included in the PR description
• New files have MPL-2.0 license header
• Adequate test coverage exists to prevent regressions
• Major classes, functions and non-trivial code blocks are well-commented
• Changes in component dependencies are properly reflected in gn
• Code follows the style guide
• Test plan is specified in PR before merging

After-merge Checklist:

• The associated issue milestone is set to the smallest version that the
  changes has landed on
• All relevant documentation has been updated, for instance:
  • https://github.com/brave/brave-browser/wiki/Deviations-from-Chromium-(features-we-disable-or-remove)
  • https://github.com/brave/brave-browser/wiki/Proxy-redirected-URLs
  • https://github.com/brave/brave-browser/wiki/Fingerprinting-Protections
  • https://github.com/brave/brave-browser/wiki/Brave%E2%80%99s-Use-of-Referral-Codes
  • https://github.com/brave/brave-browser/wiki/Web-Compatibility-Exceptions-in-Brave
  • https://github.com/brave/brave-browser/wiki/QA-Guide
  • https://github.com/brave/brave-browser/wiki/P3A

Test Plan:

Perform a sanity test to make sure balances are displayed correctly in wallet.
Most of the screens should have faster rendering since we are reading the cached value. But some screens have limited improvement since we are still asynchronously fetching asset prices and NFT metadata.

[StephenHeaps]

Do these stores need WalletUserAssetDataObserver.cachedBalanceRefreshed() implemented?

[github-actions]

[puLL-Merge] - brave/brave-core@24072

Description

This PR updates the logic for fetching and caching token balances across various wallet stores in the Brave iOS app. It introduces the use of WalletUserAssetDataObserver to observe changes in cached balances and trigger updates in the UI. The motivation seems to be to improve performance by utilizing cached balances where possible instead of always fetching from the network.

Changes

Changes

• AccountActivityStore.swift:
  • Updates the logic to first fetch balances from cache if available, falling back to fetching from network if not found in cache
  • Adds support for WalletUserAssetDataObserver to observe balance changes and trigger updates
• AccountsStore.swift:
  • Updates balance fetching logic to use cached balances if available
  • Adds support for WalletUserAssetDataObserver
• AssetDetailStore.swift, NFTDetailStore.swift, NFTStore.swift, PortfolioStore.swift, SelectAccountTokenStore.swift, SendTokenStore.swift, SwapTokenStore.swift, TransactionConfirmationStore.swift:
  • Similar changes to use cached balances and support WalletUserAssetDataObserver
• RpcServiceExtensions.swift:
  • Removes unused fetchTotalBalance function
• WalletUserAssetManager.swift:
  • Removes data observers on deinit

Possible Issues

• The changes add more complexity around balance fetching and caching. It will be important to thoroughly test various scenarios to ensure balances are being accurately cached and invalidated when necessary.
• There is some code duplication around the caching logic that could potentially be refactored and consolidated.

Overall, the changes seem reasonable to improve performance by better utilizing cached data. Just need to be diligent with testing and monitoring after the changes to watch out for any balance inconsistencies or caching bugs.

[StephenHeaps]

No need for assignment to transactionsSections (causes uneeded view update), otherwise lgtm.