feat: Make SESSION_COOKIE_AGE explicit

[robrap]

Making SESSION_COOKIE_AGE explicit to make it more clear that we have a session timeout, and how long it is.

Description

Describe what this pull request changes, and why. Include implications for people using this change.
Design decisions and their rationales should be documented in the repo (docstring / ADR), per
OEP-19, and can be
linked here.

Useful information to include:

• Which edX user roles will this change impact? Common user roles are "Learner", "Course Author",
  "Developer", and "Operator".
• Include screenshots for changes to the UI (ideally, both "before" and "after" screenshots, if applicable).
• Provide links to the description of corresponding configuration changes. Remember to correctly annotate these
  changes.

Supporting information

Link to other information about the change, such as Jira issues, GitHub issues, or Discourse discussions.
Be sure to check they are publicly readable, or if not, repeat the information here.

Testing instructions

Please provide detailed step-by-step instructions for testing this change.

Deadline

"None" if there's no rush, or provide a specific date or event (and reason) if there is one.

Other information

Include anything else that will help reviewers and consumers understand the change.

• Does this change depend on other changes elsewhere?
• Any special concerns or limitations? For example: deprecations, migrations, security, or accessibility.
• If your database migration can't be rolled back easily.

[robrap]

@kdmccormick @feanil: How do you feel about making this explicit? Silly me had to chase this down for a while, because I didn't actually get where it was configured, and we looking through code, etc. I'm going to make it explicit in our settings if you don't like the idea of adding it here. I know we wouldn't want to make every default setting in the world explicit, but this seemed ok to note.

Anyway, feel free to thumb-up or reject. It's a proposal. Thanks.

[kdmccormick]

Hey @robrap , two pieces of feedback here:

• Our goal is to push all of the production-ready defaults up into common.py, so I would rather not add new default values here in production.py.
• I am wary of adding any no-op code. Without a clear criteria to answer the question "when do we redundantly set settings to their django defaults?", I would rather not add these sort of redundant defaults.

[robrap]

@kdmccormick: That makes sense. Thanks for saying no to something that doesn't feel right. Docs would be better, but I wasn't certain where to put it. What do you think of this alternative, since I looked at this code: #36126.

Closing this PR as well.