Deal with duplicated accounts in ethstore

[svyatonik]

following (3) from #4366

After adding vaults functionality, duplicated accounts in keys-dir && vaults directories became a real pain. When vault is closed, we do not know nothing about its contents (addresses) => we can't fail when same account is inserted to the root dir/another vault.
After vault is reopened, there are two accounts for same address - one from root dir, another from vault. The problems are:

1. these are displayed as single account in UI;
2. UI doesn't show that vault contains duplicated accounts - vault looks empty for the user;
3. duplicated accounts could have different passwords => it is hard to guess password for duplicated accounts, which came from different vaults;
4. if that is true: https://github.com/paritytech/parity/wiki/FAQ#how-do-i-import-my-keys-from-geth (although it doesn't works for me), then moving geth account to vault could lead to auto-reimporting it on each restart to the root dir => duplicated accounts.

I do not see any good solution to this right now, as there's no point, where we can fail duplicated account insertion (vault with dup-account can be closed during insertion). To me, options are:

1. fail to open any directory, which contain duplicated accounts. I.e. when starting parity - if root dir contains duplicated accounts => fail with descriptive error message. When vault is opened - check if open will lead to duplicating any accounts && fail in this case.
2. add vault argument to all account-related RPC (I suppose this is not an option) + show duplicated accounts in UI with 'vault-tags'
3. do warn!() when open containers with duplicated accounts, but it is not a solution, actually.

[3esmit]

If you watch an account at ADDRESSBOOK and later import it to parity it won't appear at ACCOUNTS.

[5chdn]

This issue is labelled with annoyance: The client behaves within expectations, however this "expected behaviour" itself is at issue. It's inactive since February, neither assigned nor linked to any milestone.

@paritytech/core-devs Please decide on a deadline and add an assignee within 7 days, thanks!

[folsen]

@svyatonik how much of this is related to UI vs client-side. If there is still relevant work to be done on client-side to solve this problem, could you describe that more specifically so that people can pick up the work and fix it.

[svyatonik]

iirc I had a talk with @jacogr && we decided that it is the problem of UI (the way it handles duplicate accounts). But this can be solved on server-side as well (see solutions above). So this description is the most specific description I have :)

[folsen]

Then closing this issue due to UI being moved. Can reopen for handling node-side if there's a large demand.