Fix: attempt db rename during reset

[thekaveman]

Updates the bin/init.sh script to first rename the existing database file before deleting, in the case of a DB reset.

This is a follow-up to #1775 -- with the Sqlite file stored in an Azure SMB fileshare, when we rm django.db the file is only marked for deletion in Azure, which could take a few minutes.

In the meantime, python manage.py migrate is attempting to recreate/write to the file that may still exist (and locked for deletion). We're seeing an increase in healthcheck failures as the app restarts and finally clears the file lock:

2023-12-01T17:35:15.514065207Z + bin/init.sh
2023-12-01T17:35:15.554876476Z + [[ true = true ]]
2023-12-01T17:35:15.555739988Z + DB_DIR=./data
2023-12-01T17:35:15.555886290Z + DB_FILE=./data/django.db
2023-12-01T17:35:15.556020892Z + rm -f ./data/django.db
2023-12-01T17:35:15.604529968Z + python manage.py migrate
...
2023-12-01T17:35:20.778732650Z django.db.utils.OperationalError: unable to open database file
...
2023-12-01T17:35:20.847969505Z Waiting up to 2 seconds
2023-12-01T17:35:20.847989805Z Press Ctrl-C to quit
...
2023-12-01T17:38:08.788212280Z + bin/init.sh
2023-12-01T17:38:08.895594785Z + [[ true = true ]]
2023-12-01T17:38:08.895632085Z + DB_DIR=./data
2023-12-01T17:38:08.895648586Z + DB_FILE=./data/django.db
2023-12-01T17:38:08.895652986Z + rm -f ./data/django.db
2023-12-01T17:38:08.916634280Z + python manage.py migrate
...
2023-12-01T17:38:13.808992207Z Operations to perform:
2023-12-01T17:38:13.810500928Z   Apply all migrations: admin, auth, contenttypes, core, sessions
2023-12-01T17:38:13.818119733Z Running migrations:
...

[github-actions]

Coverage report

The coverage rate went from 90.87% to 90.87% ➡️
The branch rate is 85%.

None of the new lines are part of the tested code. Therefore, there is no coverage data about them.