Recipes using useradd.bbclass to create new user and group accounts in
STAGING_DIR_TARGET (the target sysroot) don't re-create their accounts
when they rebuild after a clean base-passwd rebuild. A rebuild of
base-passwd resets /etc/passwd and /etc/group in the sysroot, but
bitbake doesn't seem to propagate this change up to dependent recipes
like cronie, which adds more accounts to these files. So if cronie
rebuilds after a clean base-passwd build, the sysroot isn't updated with
cronie accounts.

This can fail other downstream recipes which expect cronie's crontab
group to be there by depending on cronie.

Reproduction steps, MACHINE=x64:

bitbake base-passwd cronie
grep crontab tmp-glibc/sysroots/x64/etc/group   --> contains a crontab group, as expected
bitbake -c cleanall base-passwd
bitbake base-passwd
grep crontab tmp-glibc/sysroots/x64/etc/group   --> missing crontab group, as expected
bitbake cronie
grep crontab tmp-glibc/sysroots/x64/etc/group   --> still missing crontab group

Workaround:

bitbake -c cleanall cronie
bitbake cronie
grep crontab tmp-glibc/sysroots/x64/etc/group   --> crontab group is back

The difference between the second and third builds of cronie appears to
be an sstate-cache hit, which doesn't update the sysroot with cronie
accounts.