(stable8.3) perf(polls): paginate poll list and load navigation counts separately

[hamza221]

What changed:

• Added pagination
• Only load the polls count instead of all polls for sidebar tabs
• PollMapper::findForMe() narrows the candidates in SQL per category
  (access, owner, votes, expiry, relevance, view superset via EXISTS
  subqueries) vs Filtering client side

Impact -> Testing with a test instance with 10k fake polls in the db

Now:

• Initial load -> 1.7s
• Opening Participated (0 polls) -> Instant
• Opening My polls (917 polls ) -> 0.404 s

Before:

• Initial load -> 25.77 s
• Opening Participated (0 polls) -> Instant
• Opening My polls (917 polls ) -> instant

🤖 AI (if applicable)

• The content of this PR was partly or fully generated using AI (N/A)

[hamza221]

Hello @dartcafe,
We need this performance fix along other fixes on the newly created stable8.3 branch for a customer who can't upgrade past 8.3.x
I also think this approach can help make polls more scalable for other versions too. as the app gets slow once you have access to a big number of polls (10k in this case).
The goal is to create fixes on this new stable branche then tag v8.3.11 from here. would you be okay with that or do you maybe have another preference.

[dartcafe]

You can take over the stable-8 branch, because I think I will not be able to get further into it ATM, neither test it.

If you want to adopt it to the main branch, there is a toggle in the Polls admin settings to disable loading polls to the sidebar:

Since for most people the default behavior is no performance issue, an introduced pagination should be an admin setting.

[dartcafe]

Without further testing...

[hamza221]

Thank you for the quick answer, I'll take care of the release for this branch

[hamza221]

Since for most people the default behavior is no performance issue, an introduced pagination should be an admin setting.

I agree that this is a bit 'niche' I don't expect most users to have such big number of polls and face this issue, that's why I created the PR against stable8.3.

I'll see if a PR against main would make sense and propose it, if it does.