Remove DEV_MODE and USE_FAKE_FXA_AUTH, replace with PROD_MODE and FXA_CONFIG

[KevinMind]

Fixes: mozilla/addons#15331

Description

This commit introduces several changes to simplify and improve the authentication and environment configuration:

• Replaced DEV_MODE with PROD_MODE derived from version JSON instead of environment variable
• Removed USE_FAKE_FXA_AUTH setting replaced with FXA_CONFIG to control fake authentication
• Simplified conditional logic around development and production environments to rely on stable build time variables

Context

This patch simplifies the configuration of "prod" versus "dev" mode by relying on build time parameters that reliably inform what kind of server to run. Environment variables can be overwritten and have no direct connection to the build, but get_version_json can tell you exactly waht kind of image you are running.

Additionally, sometimes you want to run in prod mode, but don't want to setup a real authentication server. Now you can do that because we use a more granular check for fake FXA based on the presence of valid fxa credentials at runtime.

Testing

Dev mode

Run in dev mode

make up DOCKER_TARGET=development

App should run in dev mode with debug toolbar and non compiled assets

Prod mode

Run in prod mode

make up DOCKER_TARGET=production

Expect compiled assets, no debug toolbar (unless DEBUG=True is explicitly set)
and finally, fake fxa should still be used by default.

Real auth

To run with real auth you must set the environment variables

FXA_CLIENT_ID=id
FXA_CLIENT_SECRET=secret

and run in either dev or prod mode. Try both.

Checklist

• Add #ISSUENUM at the top of your PR to an existing open issue in the mozilla/addons repository.
• Successfully verified the change locally.
• The change is covered by automated tests, or otherwise indicated why doing so is unnecessary/impossible.
• Add before and after screenshots (Only for changes that impact the UI).
• Add or update relevant docs reflecting the changes made.

[diox]

The main benefit of the explicit settings checks was to avoid accidentally having fake FxA enabled on dev/stage/prod if an environnement variable wasn't set properly (something we can't easily see/test/control ourselves until after deployment).

We should at least keep something like USE_FAKE_FXA_AUTH, change it ALLOW_FAKE_FXA_AUTH and use it here on top of the check on client_id being . to keep the same guarantee.

[KevinMind]

I was thinking about a Django system check that raises if those values are not set in production. Wdyt?

[diox]

But how would that check pass on local envs then ? You'd end up needing a similar mechanism to special case local envs ?

[KevinMind]

I was actually thinking we could have a django check that ensures those values are not '.' in production. Would that also solve the issue? Production pods would just fail if they start without proper auth configured.