kpasswdserver cleanup

Hi everyone,

while working on encryption support for KArchive and the archive KIO 
worker (what lets you browse “archives as folders”) I had to dive deep 
into kpasswdserver.

It is completely designed around window IDs which obviously doesn’t work 
on Wayland. Trying to fix it using XDG Foreign and XDG Activation is 
hindered by the fact that there’s a tonne of “TODO KF6 remove” and 
“deprecated, don’t use” APIs here. It also still talks to KWallet 
directly instead of Qt Keychain.

Furthermore, there’s an entire infrastructure in KDEDModule for 
“register window” and “unregister window” which as far as I can tell 
seems completely unused outside of KIO (job tracker and that then tells 
kpasswdserver). kpasswdserer uses it to expire cached credentials when 
the relevant window closes.

Is that still something that’s worthwhile or should we simplify this and 
track the app closing (unregister on the bus)? However, that probably 
won’t work with out of process workers and is likely the reason this was 
done on a per-window basis in the first place.

Do we consider kpasswdserver’s DBus API public and who is consuming it?
There’s a KPasswdServerClient class that’s used by a few (Konqueror, SMB 
KDED, print-manager) but it seems nobody (of us, anyway) is talking to 
kpasswdserver directly?

Can we nuke the old DBus API and make a new one that takes a _string_ 
window ID like the portal APIs do (and takes an options dict for future 
extensions). If KPasswdServerClient were adjusted to use it, there would 
be no release timing issues, would there?

Or just leave the old one untouched and make a kpasswdserverv2?

Or is this entire thing something we want to get rid of in favor of 
[insert portal API/qtkeychain/whatever]?

Cheers
Kai Uwe