(almost) get rid of run.php

What does this MR do?

Adds/extends Symfony based commands for the remaining usages of run.php, including the mail queue worker.

Because production/beta is still relying on run.php to execute the worker, I could not remove it yet (will need to wait until after the next release), but I artificially limited it to only work for the queue worker to discourage anyone/anything else from using it.

As a followup post-release, the entire ConsoleControl situation can be simplified by converting all of its inheritors to Commands instead. I've saved this for now, because the mail queue worker will have to stay as is anyway.

TODO: once merged, add a task to the milestone to switch over the service file in production to go through the console: https://gitlab.com/foodsharing-dev/foodsharing-ansible/-/blob/master/roles/foodsharing/templates/fs-mailqueuerunner.service

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

Currently, everything that does some kind of cronjob/background task runs in the production environment. Because of that, we would not see it break until release.

However, except for the mail queue worker, every cron job etc goes through the symfony console already.

If the queue worker is proven to work in CI/dev, it should also work fine in production, as functionally nothing has changed.

Links to related issues

How to test

Screenshots (if applicable)

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
• added to the next milestone (see https://gitlab.com/foodsharing-dev/foodsharing/-/milestones, unless it has a "for:Dev" label)
• added an entry to CHANGELOG.md
• added a short text in the release notes to /release-notes/YYYY-MM.md
• Once your MR has been merged, you are responsible to create a testing issue in the Beta Testing forum: https://foodsharing.de/region?bid=734&sub=forum. Please change the MRs label to "state:Beta testing".
  • 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.