Users and groups endpoints do not honor plone.many_users/plone.many_groups

Situation

We have a fairly large plone environment which uses pas.plugin.ldap for user management. Our Ldap-Server (Active Directory) has about 9000 Users and 260 Groups in the search scope. Since getting all users/groups takes a very long time (or fails completely due to timeouts) we enabled the options Many Users and Many Groups in the "User and Group settings" control panel. (This corresponds to the registry entries plone.many_groups and plone.many_users). This setting is honored in the Plone backend and user management works fine there.

Due to a new use case some users need to access the Volto Control panel for users and groups. We noticed that opening either one of those leads to high load on the Plone servers.

Cause of the problem

When opening either one of the user or group control panels in Volto a call to the endpoints @users and @groups is made without any parameters. This leads to them trying to get all users/groups from the backend which in turn leads to high load on the backend servers due to the high amount of users/groups.

I checked the code for the users/groups endpoints and the many_user/many_groups configuration is not taken into consideration when calling them without any parameters.

Possible solutions

1. Update both endpoints to honor the many_user/many_groups options and return an empty list if those options are set.
2. Pipe the many_user/many_groups setting through to volto (or shadow the settings in the volto settings) to disable the calls to the endpoints and just not list users/groups unless a search term is provided.

I personally think that option 1 would be the most consistent solution. However I am not quite sure if implementing this will have side-effects for other components relying on those endpoints. I'm also not quite sure if this solution should be implemented in plone.restapi or in pas.plugin.ldap. Implementing in restapi would be more consistent since the many_x options are provided by plone itself but it could also be argued that having this many users/groups directly in plone will not impart that large an impact as the same amount of users in ldap.

Option 2 kinda feels wrong to me since the actual problem is in the backend and this would only avoid the problem, not solve it. However this solution would probably impact far fewer other components.

Tested Versions

• Plone: 5.2.14 and 6.0.14
• Volto: 15 and 16 (Checked the code for 18: problem would probably also occur in this version)
• plone.restapi: 9.2.0 and 9.9.0
• pas.plugin.ldap: 1.8.1 and 1.8.2

Would you generally be open to an implementation of option 1? If yes I could try to make a PR for it or ask our contractor for a quote.

Start with the @users and @groups endpoint implementations and inspect how the plone.many_users and plone.many_groups registry settings are handled. Confirm the behavior for requests without parameters, then check that searches and existing endpoint consumers still work; done means enabled settings prevent unbounded enumeration while preserving intended filtered access.