Do not use FETCH_EAGER

[pmattmann]

Solves the same problem as #6720 - but differently.

We can completely dispense with eager-fetch, so that FilterEagerLoadingsExtension has no effect.
This way we don't have to undermine the ApiPlatform code.

Affected endpoints:

• /camp/{campId}/categories
• /camp/{campId}/checklists
• /checklists/{checklistId}/checklist_items
• /periods/{periodId}/days
• /periods/{periodId}/schedule_entries
• /days/{dayId}/day_responsibles

[github-actions]

⛔ Feature branch deployment currently inactive.

If the PR is still open, you can add the deploy! label to this PR to trigger a feature branch deployment.

[BacLuc]

Measurement with dev data is here: BacLuc@c8ffccf

[pmattmann]

Measurement with dev data is here: BacLuc@c8ffccf

We should measure with the amount of data, as is the case on prod.

[BacLuc]

I know, but testing against prod data brings its own difficulties.
Testing against the dev and feature branch deployments was a good indicator if a change will not change much, make it way better, or make it way worse.
Here are the measurements against a prod database on my laptop. (diffed against devel, prod database, on my laptop):
BacLuc@ef8229d

some requests could not be served, transactions were aborted...?
(but that happened also with the reference of devel)