For lookup reasons we currently create fake user objects in order to complete operations like an 'id' command.
Fake users were introduced as a performance improvement to reduce the number of LDAP requests. Previously we were resolving each user of each group we looked up which in some pathological condition could make us download the whole database.

Although this change did indeed boost our performance it can be further improved.
What we haven't properly taken in accoutn is that by simply crating objects we are putting pressure on our local database.
Each user object involves many operations including touching many indexes and memberof plugin operations.

The proposed solution here, is to not create fake users at all, and instead only add a ghost member attribute to the group. The attribute can be called 'ghost' and represent usernames (just like memberuid) of users that are supposedly group members but haven't been fully resolved yet.
These ghost user names are derived from the DNs of the originalmemberof attribute just like it is done today for creating fake users.

ghosts lists will need to be updated (to remove the name) when the actual user
is looked up and saved in the cache. This will avoid duplicates from showing up.

ghosts are otherwise updated only when a group is explicitly looked up in
ldap. we do not care if, in some cases a parent group may till show a
disappeared ghost from a member group and the reason is that user membership
are always relevant only when an actual user is being evaluated in the system,
and in that case the user has to be stored in the cache.
After a user is added to the DB the sysdb code should take care to do an extra
check searching for ghost=username and remove any remaning mention of the user.

ghosts may be left behing if the user memebrship changes between the time
groups are looked up and the user is actually looked up, so albeit rare it is
possible to have a stale ghosts.

we also need nto remove ghosts from non-stale groups, this can be done in 2
ways: a) as part of the sysdb search or b) by changing the memberof plugin to
remove values from ghost when it adds values to memberuid.

We should start doing only A) and add B) only if combining the modifies turns
out to be an actual performance gain, (B is more complex to handle and touches
an already complex plugin so we should do it only as an additional
optimization step).

By using an attribute on the groups instead of creating actual objects we
should be able to attain important performance benefit at least in the most
pathological cases (like freeipa 2.0/2.1 where all users are part of the
'ipausers' group, so a simply ID command ends up creating one object for every
user in the ipa domain, which could be tens of thousands).