[2.x] perf: load the accepted policies of every loaded user together, whoever checks them

[imorland]

No issue: found from query profiling of discussion pages on discuss.flarum.org.

Changes proposed in this pull request:

Checking any user's permissions runs this extension's permission group processor, which needs that user's accepted policies. Other extensions check permissions for every user they serialize. On discuss, fof/ignore-users' ignored field does it for each user on the page.

#85 eager-loads the accepted policies for the users of a few endpoint relations (discussion authors, last posters, post authors). Users reached through any other relation still loaded their accepted policies one query at a time. On one discuss discussion page that was 19 queries for 16 users: the users who liked posts (flarum/likes likes) and the posts' editors (editedUser).

This makes the loading independent of how a user was reached:

• LoadedUsers keeps track of the users loaded so far, through Eloquent's retrieved event, in a WeakMap, so tracking never keeps a user in memory, for example in a queue worker.
• When a user's accepted policies are needed and aren't loaded, PolicyRepository::state() loads them for that user and every tracked user still without them, in one query (chunked at 1000 users, for the database's limit on bound parameters).
• With no policies at all, a user's state is now empty without looking anything up. Before, every permission check still loaded the user's (empty) acceptance rows.

#85's eager loads and its PolicyStateBuffer are unchanged.

Reviewers should focus on:

• The batch only covers users already loaded when the first one is needed. The actor's own check usually runs as the request starts, before anyone else is loaded, so that is a separate query; everyone loaded afterwards is batched together.
• Unsaved users (guests) are skipped: they have nothing to load, and reading the relation doesn't query.
• PolicyStateForLoadedUsersTest lists posts with their editedUser for six editors, one of whom hasn't accepted the required policy, while a test field checks startDiscussion on every serialized user, as other extensions do. It asserts the number of acceptance queries and that the editor who hasn't accepted is still restricted. Each user's groups lookup is exempted from the repeated-query check, with a comment: that's the cost of the extension doing the check.
• The commits are in that order so CI shows the new tests before and after the change:
  • the first commit (tests, old code) failed with seven acceptance queries, one per user: run;
  • the second commit passes, with three acceptance queries (the actor's own check, [2.x] fix: Batch policy state loading to avoid one pivot query per serialized user #85's post author eager load, and one for all the editors), or one with no policies ([2.x] fix: Batch policy state loading to avoid one pivot query per serialized user #85's eager load): run.
• A test:integration:filter composer script runs single test classes through composer.

Screenshot

N/A

Confirmed

• Frontend changes: tested on a local Flarum installation. (No frontend changes.)
• Backend changes: tests are green (run composer test).

Required changes:

• Related Flarum core extension PR's: none.