[lgelauff]

Fixes #619 (very likely: see below).

What goes wrong

Activating a round builds one Vote object per task, and loads one RoundEntry object per entry, all held in
the request until it commits, and inserts the tasks one row at a time. For large rounds that needs more memory
than the webservice has.

On montage-dev (512 MiB container, 4 gunicorn workers), activating a round of 21,516 tasks got the container
OOMKilled after 6.6 s: the browser got a 503, the round stayed paused with no tasks (the transaction rolled
back), and nothing was logged, because the process was killed rather than raising an error. That matches #619,
an activation failure on production without a clear cause.

The fix

create_initial_rating_tasks and create_ranking_tasks now read only the shuffled round-entry ids and insert
the tasks with executemany in chunks of 5,000; pymysql turns each chunk into multi-row INSERTs. Which juror
gets which entry is unchanged. The session is flushed before the inserts and expired after them, so nothing
loaded earlier in the request is stale.

Measured locally (SQLite, 21,500 tasks): peak Python memory 219 MiB → 12 MiB, time 15.6 s → 1.0 s.

Tests

• New test_activation_inserts_tasks_in_batches: a 40-task round is inserted with 1 INSERT (master: 40), each
  entry gets quorum different jurors, and the rows look as before (status active, empty flags, a
  create_date). It fails on master. It works with and without the background-import PR (Background import job: imports run in a worker (backend) #630).
• Backend suite: 15 passed, 1 xfailed; with Batch entry inserts so large category imports finish within the request timeout #623, Lock the round when activating it, so a double click can't create every task twice #626, Read Commons category members from the links replica, and batch file lookups #628, Background import job: imports run in a worker (backend) #630 and Background import job: rounds show their import status (frontend) #631 merged in: 134 passed, 1 xfailed.
• On montage-dev (MariaDB, 512 MiB container), with the other PRs above: the 21,516-task round that was OOMKilled before activated in 4.5 s, with 21,516 tasks; a juror then got tasks and cast a vote as usual.

Not in this PR

• Reassigning tasks (after changing jurors or the quorum) still loads and updates them one ORM object at a
  time, so it can hit the same limit on very large rounds.
• The webservice's memory limit is unchanged.

Written with Claude (Claude Code) on behalf of @lgelauff.

🤖 Generated with Claude Code