This bug is created as a clone of upstream ticket:
https://fedorahosted.org/sssd/ticket/1376

In many cases, actually being able to list the members of a group is unnecessary. For the most part, access-control schemes will rely on whether a user's environment includes them as a member of a group (via initgroups() or getgroups()), and NOT by looking up the group to see if the username happens to be present.

This provides us with an opportunity to increase our performance on such systems. We should add a new per-domain option: {{{ignore_group_members}}}.

This would have the following effects:
1. When populating the results to send back to the client, we would suppress the membership list. In other words, the groups would appear to be empty.
1. When doing LDAP lookups for the groups (for any schema), we would filter out the 'member' and 'memberuid' attributes, so that our direct lookups would skip downloading large memberships or processing nested groups.

One side-effect to this would be significantly-increased performance when running {{{id <username>}}}.

The trickiest piece of this functionality would be ensuring that we don't delete existing member/memberOf linkages from the cache during group lookups that were put there by previous initgroups() requests. Thus, when this option is in play, member/memberOf should only be managed by initgroups() calls.

As one last data point, this is apparently the default behavior for winbind, which explains the visible performance disparity between these two projects when performing {{{id <username>}}}