Ran into this in the wild when a customer had 600,000+ incidents in the system and ITIL users were trying to look at a Related List of incidents. The AJAX transaction calls M2MList but no HTTP response ever comes back. I can see in the log that it is querying 100 incidents at a time and then blocking each of them, one-at-a-time when evaluating for write ACL access. Then it queries another 100 incidents and blocks those too. After a few minutes the transaction times out.
I was successfully able to reproduce this out-of-box.
This happens only in Dublin and later because of the addition of the isBucketFull check in M2MList.
Steps to Reproduce
To avoid this issue, before clicking "edit" on an affected related list, a user can build a filter that will exclude all records to which they do not have write access.
For example, in the base system there is an ACL that restricts ITIL users from writing to Incidents whose Incident State field is Closed. This can cause the slushbucket for related lists on the incident table to load very slowly. To avoid this slowness, create and run the following filter on the affected related list:
Related Problem: PRB601643