Improve bell notification via websocket

Part of #975

What does this MR do?

Creating a poll in a region with many people causes a timeout, because inserting entries into the poll's table (fs_foodsaver_has_poll) and sending bell notifications is done for each user individually.

• use queries that insert 100 people at once instead of each person individually. This is the same fix that we used for events in #774 (closed)
• send websocket notifications to many users at once by using WebSocketConnection::sendSockMulti instead of sendSock

When I tested it on localhost with 2000 foodsavers, the request took 20-25 seconds of which roughly 15 seconds were caused by the websocket notifications. With this change it only takes 2 seconds.

How confident are you it won't break things if deployed?

Very sure

Links to related issues

#774 (closed), !1285 (merged), and !1709 (merged)

How to test

Steps a reviewer can take to verify that this MR does what it says it does e.g.

1. Checkout branch locally
2. Increase the number of users in the seed command to 2000: https://gitlab.com/foodsharing-dev/foodsharing/blob/ac7669a7aef2e64fd5808b4e33f9b309251ad761/src/Dev/SeedCommand.php#L397 and run ./scripts/seed
3. Login as uservoting1
4. Go to the home region -> polls and create a new poll
5. Check that you submit create the poll without a timeout
6. Login as user2 or userbot and check that you received a bell

Checklist

• added a test, or explain why one is not needed/possible...
• no unrelated changes
• asked someone for a code review
• set a "for:" label to indicate who will be affected by this change
• use "state:" labels to track this MR's state until it was beta tested
• added an entry to CHANGELOG.md
• add a short text that can be used in the release notes
• Once your MR has been merged, you are responsible to create a testing issue in Beta Testing Repo:
  • Consider writing a detailed description in German.
  • Describe in a few sentences, what should be tested from a user perspective.
  • Also mention different settings (e.g. different browsers, roles, ...). how this change can be tested.
  • Be aware, that also non technical people should understand.

Release notes text

(A short text that will appear in the release notes and describes the change for non-technical people. Not always necessary, e.g. not for refactoring.)