qml: rework auth

[accumulator]

now handles keystore-only password and defines a new set of auth methods.

[ecdsa]

This looks complicated, and I don't have time to review it today.
I think we can consider it for the next major release, but not as a bug fix to be deployed quickly.
To fix #8374, why not simply ask for the password unconditionally on startup?

[accumulator]

This looks complicated, and I don't have time to review it today. I think we can consider it for the next major release, but not as a bug fix to be deployed quickly. To fix #8374, why not simply ask for the password unconditionally on startup?

This is actually less impact than the alternative, which would need a refactor of the wallet loading logic in relation to qewalletdb, expand its scope beyond just wallet db stuff (qewalletdb is used to trigger whether a password is needed before opening the wallet, amongst other things).
Also it is IMO an improvement because it allows the auth layer to pass along (transient) passwords or other secrets without the decorated objects having to handle/assume passwords themselves. This could also be used for HWW unlock, passphrases etc.

This PR stays much closer to what e.g. the desktop client does, doesn't need refactoring of the qml wallet loading logic, does not need a password at startup for keystore-only passwords (might even be a feature instead of a bug?)

Finally, I don't think I can fully implement and test the alternative today, so that would mean a delay until after the weekend

[SomberNight]

I don't think this always behaves correctly, e.g. for a multisig wallet that has multiple keystores. This only checks the first keystore. I would prefer if we could just use wallet.check_password() directly, which has this logic encapsulated. None of the other GUIs call keystore.check_password() AFAICT.

[accumulator]

agreed, but wallet.check_password() directly calls wallet.keystore.check_password() so I'm not sure why this would be problematic