Improve sqlite configuration options

[mikerkelly]

Fixes #2268.

We think immediate mode in particular might help resolve 'database is locked' errors.

Options used here are largely following suggestions from the article https://kerkour.com/sqlite-for-servers as referenced in #2268/#2251, some of which I found Django applies by default. See commit messages for more discussion. In particular, I think we should not be using an excessively large timeout as this can cause users to wait a long time if there was a problem with the site. Let's try 5 seconds and see if the other settings changes resolve the issue, then gradually increase the value if there are still many errors.

I discovered that unfortunately we have been configuring the timeout settings for the default database incorrectly, so #1143, #1811, #2276 increasing it from 5 to 30, 60, and most recently 90 seconds had no effect. This might explain why the "database is locked" errors that they sought to remedy never improved.

DATABASES = {
    "default": dj_database_url.parse(
        os.environ.get("DATABASE_URL", default="sqlite:///db.sqlite3")
    ),
    "OPTIONS": {"timeout": 90},
}

The OPTIONS parameter is a key of DATABASES, not DATABASES["default"]. Therefore it doesn't apply to any database and does not take effect. This can be verified by checking PRAGMA busy_timeout, for example in a management command (show_db_timeout.txt). By default it's 5 seconds. Correct the structure of DATABASES and the changed setting is respected.

Added tests of the settings. I wondered if this is just testing django, but we've seen a minor error in configuring DATABASES can lead to unintended results, so let's test. Also to demonstrate that defaults do indeed take effect, and that the options work are applied to the DB / transactions as we expect.

I've attached two more throwaway management commands. One (
upgraded_transaction_fail.txt) I used to satisfy myself that changing to immediate mode fixes the "database is locked" issue when a transaction start as a read and upgrades to a write while another holds the lock. And another (profile_db.txt) to try bulk writes (I think this can be used to demonstrate that transactions that start by writing are affected by the timeout regardless of transaction mode setting). I don't think the reviewer need to look at these, it's in case they're useful for debugging etc. in future. All designed to work with class TestTable(models.Model): value = models.CharField(max_length=255) in opencodelists/models.py

Approach to testing inspired by opensafely-core/airlock#248. I noticed some of the settings they apply there from the article don't need to be set explicitly in Django as it applies them automatically. But maybe they're setting them for future-proofing or to be explicit? I might mention that to team RAP.