Query of existing entity permissions during view permission generation
could cause timeouts or SQL placeholder limits due to massive whereOr
query generation, where an "or where" clause would be created for each
entity type/id combo involved, which could be all within 20 books.
This updates the query handling to use a query per type involved, with
no "or where"s, and to be chunked at large entity counts.
Also tweaked role-specific permission regen to chunk books at
half-previous rate to prevent such a large scope being involved on each
chunk.
For #4695
- Adds filtering to the watched items list in notification preferences
so that deleted (recycle bin) items are removed via query.
- Adds relations and logic to properly remove watches upon user and
entity delete events, to old watches in database do not linger.
- Adds testing to cover the above.
Did not add migration for existing data, since patch will be close to
introduction, and lingering DB entries don't open a security concern,
just some potential confusion in specific potential scenarios.
Probably not work extra migration risk, although could add in future if
concerns/issues are found.
Related to #4499
Added test and changed logic to properly check the view permissions for
the notification receiver before sending.
Required change to permissions applicator to allow the user to be
manually determined, and a service provider update to provide the class
as a singleton without a specific user, so it checks the current logged
in user on demand.
Added support for mulit-line endpoint descriptions via blank
intermediate lines in php controller method docblocks.
Also tweaks endpoint header design for better flexing and alignment.
Previously additional roles would only partially apply (system or "all"
permissions). This aligns the query-handling of permissions so that
additional roles will be used for permission queries.
Adds migration to detach existing roles as a safety precaution since
this is likely to widen permissions in scenarios that the public user
has other roles assigned already.
For #1229
