Adjust default SECRET_KEY to use `dj::insecure` prefix and add matching deployment system check.

[Carlton Gibson]

​Recent thread on the mailing list about making the default settings more 12 factor friendly. (Related to similar discussions in say #20081.)

Conclusion there was that environment variables are only one way to go. (...)

In the discussion it came up that we could prefix the generated SECRET_KEY with say, dj::insecure and then add a deployment system check to ensure that wasn't used in production. (Paraphrasing various points: might not be 100% robust but would capture most cases.)

So:

• Prefix secret key in project template.
• Add system check to ensure secret key does not have prefix.

[René Fleschenberg]

Shai Berger suggested an alternative approach: Marking the string as insecure by making it an instance of a custom str subclass (​https://groups.google.com/d/msg/django-developers/CIPgeTetYpk/3a0lkAu-BgAJ). I am not sure which of the two approaches we prefer.

[Mariusz Felisiak]

Replying to René Fleschenberg:

Shai Berger suggested an alternative approach: Marking the string as insecure by making it an instance of a custom str subclass (​https://groups.google.com/d/msg/django-developers/CIPgeTetYpk/3a0lkAu-BgAJ). I am not sure which of the two approaches we prefer.

Prefix is fine, IMO.

[Mariusz Felisiak]

​PR

[Shai Berger]

Replying to felixxm:

Replying to René Fleschenberg:

Shai Berger suggested an alternative approach: Marking the string as insecure by making it an instance of a custom str subclass

Prefix is fine, IMO.

Missed this earlier... prefix is fine IMO too.

[Mariusz Felisiak <felisiak.mariusz@…>]

In b7f5003:

Fixed #31757 -- Adjusted system check for SECRET_KEY to warn about autogenerated default keys.

Thanks Nick Pope, René Fleschenberg, and Carlton Gibson for reviews.