fix: Emit AccountsItemChanged when own key is generated/imported, use gray self-color until that (#7296)

[iequidoo]

See commit messages.
Replacement for #7289. Tested manually in Desktop. Will add tests if the approach is agreed.
Close #7296

[r10s]

as key import is mentioned in #7289 as a reason to no wait for key: importing own key is no longer supported. so we can probably wait until key is generated, that would not add additional compleyity and states

apart from that, where is self-color acutually used for self? on avatar selection? there maybe show an icon similar to android/ios, nudging ppl to set an avatar

[link2xt]

Will add tests if the approach is agreed.

It's difficult to understand what the issue is, better open an issue with the description of a bug first.

There is some description in #7289, but that is also a PR.

[Simon-Laux]

apart from that, where is self-color acutually used for self? on avatar selection? there maybe show an icon similar to android/ios, nudging ppl to set an avatar

in desktop it is used in account selector and settings, which is also the case in iOS.

For the avatar selection I tend to agree that it may make sense to nudge people into setting an avatar, but desktop already does that during account creation, just not when you open the edit dialog for the avatar/profile afterwards. so not sure if it is worth changing there.

For the account selector it is important to still have a colored icon IMO, to distinguish the accounts from each other.

---

about the issue:
I would just emit existing "AccountsChanged" when color changes (that should reload the accounts list),
I doubt that we need a new event for this, which would also need a corresponding desktop pr to listen for a new event.

[link2xt]

I still don't know what the issue is. On desktop when I create a new profile, in the profile selector on the left the color is grey, so no incorrect color is seen.

I would just emit existing "AccountsChanged" when color changes (that should reload the accounts list),

I also agree that whatever the problem is, UI developers should not need to care about the keys and know that SelfKeyAvailable means the color is changed. What matters for UI is whether the color is available or not, regardless of whether it depends on the key or address or anything else.

[iequidoo]

as key import is mentioned in #7289 as a reason to no wait for key: importing own key is no longer supported. so we can probably wait until key is generated, that would not add additional compleyity and states

Key import isn't supported explicitly in UIs, but it's still supported via sending an Autocrypt Setup Message, there are Rust and Python tests on that. Firstly i forgot about that and tried to fix the bug without using a temporary gray color. Anyway, i think the fix here isn't that complex and also we can use AccountsChanged as @Simon-Laux suggested, so it's not necessary to drop ASM support because of such minor bugs.
...
AccountsItemChanged fits better i think.

[Simon-Laux]

AccountsItemChanged fits better i think.

true

[iequidoo]

I've checked, with AccountsItemChanged the fix just works for Desktop, no changes are needed on the UI side

[r10s]

but it's still supported via sending an Autocrypt Setup Message

sending: yes. but which deltachat can import them? this should be regarded as a bug.

so it's not necessary to drop ASM support because of such minor bugs.

we really do not want to allow importing random keys via ASM or elsewhere - for security reasons, to make some concrete assumptions about security. avg user will never try that anyways, and we do no longer want to allow that.

so, ASM and import-keys that is never used should not rule other decisions in general

but yeah, this PR looks simple enough, and if it fixes an issue at hand, it seems fine