chore: metadata refactoring 4

[mroz22]

In this PR I am separating code from #9130 which is not features. so basically everything from #9130 except for confirm-less labeling and migration was moved to this PR.

While working on #9130 I noticed couple of problems which might have been around for long time or might have been introduced in one of the previous requests on the were merged along the way to the confirm-less labeling feature (#9108, #9218, #9262, #9270)

commits:

• 853ee53
  • labels have not been stored anymore into indexxed db for some time now and are instead loaded when provider becomes available. This commit fixes bug when labels were loaded only for selected device.
  • added e2e test to validate this
  • fixed paths of files in mocked providers in e2e tests.
• 7cc08f0
  • unifies unique id for labelable entities. Previously there was account.key and device.state and it was necessary to use in operator frequently. Now we are using everywhere entity.key abstraction narrowing defined in a newly added selector.
• 051e504
  • removes unused constants and export
• 9d88de1
  • moves code from metadataActions getLabelableEntities which was actually a selector to metadataReducer.
• 9f91aef
  • micro change. remove provider by clientId instead of type. type would work as well for now but we want to be ready for future.
• 298fca7
  • removes field device.metadata.status ('disabled' || 'cancelled' || 'enabled'). This is mostyl types simplification. Previously, metadata[encryptionVersion]... was bound with metadata.status.enabled and it was needed to use in operator in my opinion superfluously.
  • cancelled status is replaced by newly added metadata.error which is basically metadata.failedMigration field introduced in metadata encryption v2 (confirm-less labeling) #9130. When error is set, suite does not try to init metadata automatically.
• 2fc852c
  • updates unit tests, there were some antipatterns, for example mocking happend inside single "tests/its" meaning that running some of the tests in isolation did not work
• f59a696
  • just use selector in SettingsGeneral component.
• cb4e79d
  • in metadataActions we need to be careful about for which device (passphrase) selected action runs. Previously, we only worked with selected device but it was not right. It was actually possible to have one device selected and trigger metadata init action for another device when trying to label another wallet in wallet modal selection.
• 4f1951f
  • revision of return types in metadataActions. in general, the more atomic the action is, the less sideefects it should have. example: encryptAndSaveMetadata action and fetchMetadata actions should never handle their errors and only return results to their caller. The reason is that caller knows whether these actions are run in batch and is in better position to handle errors. In other words - if error is handled in an atomic action we might fire dozens of notifications in case of error which we obviously don't want to do.
• e82a6ad
  • removing device.status 'cancelled' actually changes behaviour of app. we need to make a note that user cancelled labeling on device so that we know that in the next run we don't want to trigger this dialogue again. Also this field will be reused in metadata encryption v2 (confirm-less labeling) #9130 where I named it metadata.failedMigration but I believe that naming in this PR metadata.error is actually better.
  • more about it in e2e test added in later commit 8c5029c
  • this commit does not make that field persitent yet, it is added in 8c5029c
• 073e40e
  • e2e test for cb4e79d
• b86a5e0
  • e2e test to make sure that newly added account has keys added too (this is handled in metadata middleware)
• a830893
  • revision of selectors
• 8c5029c
  • addition to e82a6ad making metadata.error, while not leaking info about number of used passphrases. This information follows fate of device (remember/forget)
  • I believe that decoupling this data (device.status => metadat.error) is benefitial, but our current implementation does not have any good way how to work with relational data unfortunately :( we should investigate something like https://redux-orm.github.io/redux-orm/basics/reducers.
  • this commit also adds test that describe how suite and (un)remembered devices behave in relation to labeling
• d7f4cd5
  • mitigation for Dropbox labeling Cannot read properties of undefined #9545. when data is fetched from provider, check its shape and if it does not match the expected one fill in missing structure.
  • it would still be nice to find the root cause of Dropbox labeling Cannot read properties of undefined #9545 but I really could not spot the problem, maybe whoever is reviewing this has better eyes.

Screamshots

Trying to enable labeling for other than currently selected device should work

When there are more saved wallets, all should load their labels after app reload. not only the selected one.

[matejkriz]

nitpick - why not just move it up or down? 🤷

[mroz22]

sometimes it is not possible. not sure how about this case. here I guess motivation might have been not making too many changes for review. I can try to move it as it is reviewed now.

[matejkriz]

I'm sorry for the nitpicks, feel free to close them directly or even ignore them. In general it looks great and works so far very smooth 🎉

[matejkriz]

🎉 Let's rebase it