Improve experience of "select all" when there are +500 reports

[latin-panda]

What feature do you want to improve?
Currently the report's "select all" is used to bulk delete reports. Maximum number of reports that "select all" can select is 500, however the user can keep scrolling in the left hand side list and pass over those 500 reports, because the list has infinit scroll. So the user can load 600 reports but only 500 are selected by "select all" (see video below). Selecting all those reports get the system slow, the user actually needs to wait some seconds to see the reports selected.

Because the user can select up to 500, the system attempts to retrieve all those summary documents, so when a report expands then it can show its content, however since there are too many selected, it gets slow and most of them shows "unknown sender" instead of the contact name (I've opened a separate ticket for that race condition).

Describe the improvement you'd like
Improve the system performance by processing smaller batch of reports and clarify what is "select all" since having infinit scroll makes it confusing.

Describe alternatives you've considered
Many other systems (like gmail) has implemented regular pagination, then when the user clicks on the "select all" it will select all the items of the current page, a page can have 50 records. If they want to see the next page, then the all items from page 1 are deselected, and items from page 2 load and appear deselected as well. The user can select all from one page only.

This approach would help selected reports to load faster (instead of selecting 500, now is 50), it won't stress the devices, it won't stress the system by attempting to delete too many docs, and it's more understandable since the user will know the meaning of "select all" scope, a current page of 50 - instead of infinit scroll and let them guess the maximum number (500).

Additional context
This topic came up as part of the bulk delete redesign (comment)

Video: Current behaviour in v3.17

Screen.Recording.2022-11-03.at.9.58.41.am.mp4

[latin-panda]

FYI @michaelkohn @n-orlowski