Consolidate duplicate LMS and CMS settings into platform wide settings

[wgu-taylor-payne]

Overview

#36941 introduced the openedx/envs/common.py settings module as a place to put settings shared across the LMS and CMS. In that PR, explicitly shared settings (ones that were being imported into cms/envs/common.py from lms/envs/common.py) we're brought up into openedx/envs/common.py.

This task is to build upon that work and now bring up any setting which is declared in both lms/envs/common.py and cms/envs/common.py and which shares the same value. Make sure to bring any documentation along, and merge the documentation together appropriately if it differs between the LMS and CMS. The settings annotations defined in openedx/envs/common.py will appear in the Platform-Wide Settings section of the settings reference.

Testing

Use the same, or a similar approach to #36941, to make sure that the rendered settings between master and the feature branch do not differ in any significant way.

Notes

This task is part of the effort to simplify settings as outlined in ADR 0022 - Django settings simplification.

[kdmccormick]

There will be some shared settings whose values are consistent between LMS and CMS, and it will be obvious how to consolidate those. For settings whose values differ, how do you think you will handle those (or will you skip them for now)?

[wgu-taylor-payne]

@kdmccormick I was planning on skipping settings where the values differ for now, but maybe that is something that we could look at doing next.

Depending on the value of the setting it may need to stay in cms/envs/common.py or lms/envs/common.py. I think we could find settings, though, where part of the value is common between the two, and then part is custom to the respective application. In such cases, we could raise the common part up to openedx/envs/common.py and make it a derived setting, where the part that is custom to application (cms or lms) is referenced in the derived setting, but the value is defined in its respective common.py file.

[kdmccormick]

I was planning on skipping settings where the values differ for now, but maybe that is something that we could look at doing next.

SGTM

I think we could find settings, though, where part of the value is common between the two, and then part is custom to the respective application. In such cases, we could raise the common part up to openedx/envs/common.py and make it a derived setting, where the part that is custom to application (cms or lms) is referenced in the derived setting, but the value is defined in its respective common.py file.

Agreed, I think that will be a good approach for many settings.

(Just thinking out loud: For a setting whose value has no parts at all in common between LMS and CMS, we could put just a value-less type declaration in openedx/envs/common.py, e.g. PROJECT_ROOT: str. This would allow us to consolidate the setting's documentation into one place without having to put an LMS-specific or CMS-specific value into the platform-wide defaults. The only problem with that is that we could not specify a single .. setting_default annotation. But maybe there is a way around this... I'll keep thinking.)

[kdmccormick]

This approach looks great to me 👍🏻

[kdmccormick]

at risk of stating the obvious: if you start this work soon, I'd base it off of Ram's branch, since many of those settings previously nested within FEATURES will match between LMS and CMS.

[wgu-taylor-payne]

Good point, I'll do that.