Stop sending all known groups to the frontend ACL UI

[LukasKalbertodt]

Currently, the ACL UI loads all known groups from the backend. That's not the case for "known users", which are returned by the searchKnownUsers API, but only users matching the search string are returned (with a fairly low limit). For institutions that only have a handful of known groups, that is absolutely no problem. But for those who automatically generate groups from course data, for example (with one or more groups per course), resulting in many thousands of groups, this becomes a problem.

The main reason why we can't simply do it like we do for users is: relationships between groups. What the frontend needs is the sub-graph including all groups configured in the UI. Only then can we properly determine subset relationships to show warnings.

Additional, this is made more complicated by the fact that we also want to get all the required data from the initial GraphQL request. When loading the "edit event ACL" page, there should be one GraphQL request and then everything should be rendered. So the event.acl API also needs to give us all required information in case we do not also load all group data. (I mean, this requirement is not thaaaaat important I guess. Two requests wouldn't ruin UX.)

Expected data size

One example: a university has 1000 courses per year. Say 3 groups per course. And courses over 10 years. Thats 30k groups. For now we only care about the compressed size. Let's say each group name has like 10 incompressible bytes. From an ETH dataset, the average course title is 30bytes long, also assumed to be incompressible. With all data, that's roughyl 1MB of data. When only sending the core graph and no titles, that's more like 100KB of data.

But real universities could have way more than 30k groups. So yeah, sending all courses in full is not ok. Sending the core graph miiight work, but still doesn't sound great.

Possible solutions

1. avent.acl and searchGroups would include an additional field auxGraph that is the sub graph required to solve all questions.

• Makes everything a lot more complex, determining the required sub graph is not trivial and required the frontend to also send what roles it is interested in. And sending that on every keystroke might not be a lot better than just downloading the graph once.

2. event.acl and searchGroups would flatten the graph so that each roles implies also contains roles indirectly implied.

• That implies list could be long, though it's unlikely. Sorting would work by implies.length, could even get rid of our frontend graph completely.
• Determining the flattened list isn't trivial, i.e. would require loading/caching the whole graph in the backend.

3. Have an API returning all non-leaf nodes from the graph, without titles. Could still be uncomfortably large for huge instititions.
4. Model implies rules as a list of regex/wildcard and let admins configure it like that. That's what the vast vast majority of relationship will look like. If there are only a handful of groups, sure they are "unique". But as soon as there generated groups, it's likely that ROLE_COURSE_\d{10}_ADMIN implies ROLE_COURSE_\1_STUDENT and that almost all relationships can be moddeled by a handful of regex.

• What if implies relationship cannot be compressed like that?
• Are we forcing admins to do compression for us? Or is this even more convenient/intuitive to configure this way?

5. Like (4) but derive the regex rules from the data as currently given.

• Sounds interesting but potentially dev-time costly.

It seems like after I discussed this last time, I preferred (2). But not entirely sure anymore.

Caching

Many of these solutions would be slow if the backend would have to load the full table of groups from the DB and build a graph from it each time. So it would be highly useful to cache the graph. This is somehow possible with postgres. We can have a separate connection that listens and only returns/wakes up when the data was changed.