Major waitlist transition fixes

[h1divp]

General flow of things (copied from discord):

1. send api post request to /events/{event-id}/begin-waitlist-transition
2. the api queues a task for the waitlist transition to be scheduled on the bat queue
3. the bat worker handles this task, creates a scheduler, and schedules the TransitionWaitlist task set for 72hrs
4. bat worker handles the task timely, calling an application service function which performs moving all accepted&non-confirmed users to waitlist, and accepting 50 oldest waitlisted, queues emails, and the email worker sends them all
5. once acceptanceQuota - totalAccepted < 50 ("acceptanceCount") the scheduler is shutdown

Beyond this another route /events/{event-id}/shutdown-waitlist-scheduler has been made. It also queues a task for the scheduler to be shutdown from the BAT Worker, as the api has no access to the scheduler.

Fixes

See the commit history. The most important ones were switching the logic for shutting down to check for attendee count, not accepted application count. Also, accepted applicants (ie. accepted unconfirmed users) are now waitlisted, instead of all accepted users.

Config changes

This has been documented in apps/api/env.dev.example. however for clarity i will include the new parameters in this pr with defaults:

...
ALLOWED_ORIGINS="localhost" # URLs in comma seperated list
EMAIL_TEMPLATE_DIRECTORY="../../internal/email/templates/"

# (((NEW))) Application waitlist
MAX_ACCEPTED_APPLICATIONS=500
ACCEPT_FROM_WAITLIST_COUNT=50
ACCEPT_FROM_WAITLIST_PERIOD="@every 72hr"
# ACCEPT_FROM_WAITLIST_PERIOD="@every 15s" # use this for testing
...

Known issues

• The scheduler is touched in a application service function and a bat service function. But the BAT Worker will be the only one who uses these functions. In the case that the api touches these (as it has access to both services), unexpected behavior or a panic may happen.