This reverts commit a666712102be7ef4dd48202cc2411921fc4d392b.

This broke adding new users when not setting realname or adminflag (i.e.
at present there is no way to create a !admin user at all).

Distributions, as we are still 3 weeks away from 5.8.5 I'd advise patching
this to restore working behavior for the time being.

The problem in particular is that the model gobbles up setData requests to
new rows and forwards them to newUserSetData which in turn caches them
until username&realname&admin are present and only then forwards the call
to accountsservice. By calling setData on-demand the three fields are not
set unless they in fact all where "toggled" from their default.

I suggest that the noop decision be moved into the setData itself. In there
it should be possible to accurately decide whether or not the data
actually changed and accountsservice needs to be called.

(Ideally though IMO the collection in newUserSetData should be gotten
rid of. I haven't had a close look, but creating the user with random
data for everything but username and then manipulating it on the
subsequent setData calls should be a more future-proof and reliable
approach)

BUG: 373276
CCMAIL: kde-distro-packagers@kde.org
CCMAIL: larrosa@kde.org
PHAB: https://phabricator.kde.org/D3102