Consider caching membership data for every group (including subgroups)
Currently we require to know membership data (groups and subgroups) for Epics. When pinging people, when checking authorizations, etc...
Using Group#direct_and_indirect_users
is very expensive, with @dblessing finding a 5x increase in SQL times when using it
We should consider caching membership data per each group in a separate table and use this table for any and all membership lookups, effectively denormalizing the data. (A member of a subgroup for example should show up for both the parent group and the subgroup).
This does mean that write operations could take a hit though, as we have to compute all the parents in the hierarchy when updating membership data for a subgroup.