Update process for docker compose is wrong

[mathemancer]

Description

Currently, the update process for a docker compose installation doesn't work as documented. If you try to upgrade from 0.1.3 to 0.1.4, your installation will cease to recognize its Django database under some (most) cases, causing distress. No data is lost, but manual intervention is required in order to reattach the service to the Django DB. This is because the DJANGO_DATABASE_URL is no longer supported by the new setup.

Expected behavior

Either we need to improve the environment variable handling and deprecate rather than remove DJANGO_DATABASE_URL, or we need to document how a user can update their .env file and docker-compose.yml file to match with the new variables.

I prefer the former solution, on the off chance we have users who have customized their docker compose files and don't want to change them. It's also more well-aligned with the goal of the docker compose installation style (i.e., that the user should customize or write their own docker compose configuration)

To Reproduce

Try to upgrade from 0.1.3 to 0.1.4 with non-default Django DB

Additional context

Discovered while updating the internal.mathesar.org server. Introduced by one of the last merged PRs to the branch before the release was cut (so it went unnoticed).

[mathemancer]

@kgodey I'm going to go ahead and work on an implementation assuming we want to go with the former solution. It's smoother in the short term, but kicks the can down the road (we'll eventually want to actually remove that environment variable). Thus, I'm also adding the needs: requirements label and assigning to you for a gut-check that my instinct to put off removing that variable makes sense to you from a product perspective.

Point: we avoid adding unneeded burden to upgrading to 0.1.4

Counterpoint: At some stage, users will still have to edit their .env and docker-compose.yml files with the new variables, and we probably have fewer technically-disinclined users than we will at any later stage.

[kgodey]

We discussed this in the release check-in call today and decided to go with the latter solution i.e. document how a user can update their .env file and docker-compose.yml file to match with the new variables.

Reasoning: keeping the old variable will be a maintainability burden and it's easier to make breaking changes when we have a smaller user base (i.e. now).

[seancolsen]

Addressed in #3227