Introduce Remote Dev Settings module

MR: Introduce Remote Dev Settings module (!144518 - merged)

Description

This is an issue based on Allow editor and project cloner images and tags... (#438767 - closed), which will lay the groundwork for that and other future settings/configuration work in the Remote Development domain.

This issue will implement all the "plumbing" to support this, and add a settings for the following as the initial actual examples to drive acceptance of the new behavior:

1. default_max_hours_before_termination
2. max_hours_before_termination_limit
3. default_branch_name
4. project_cloner_image_name,
5. project_cloner_image_tag

Justification for using these as initial settings to drive the introduction of the new Settings module:

max_hours_before_termination_limit is a good choice because:

• It needs to be configurable to support dogfooding (e.g. longer-lived workspaces when working on long-lived GitLab MRs, because there is a significant overhead to provisioning GDK workspaces due to the size and complexity of GitLab)
• It is used in the backend and will be an example of using settings on the backend.
• It's an integer value, and will drive support for type safety when reading ENV vars in the settings module

default_max_hours_before_termination is a good choice because:

• It is used on the frontend, and will be an example of using settings on the frontend.

default_branch_name is a good choice because:

• It shows an example of reading settings overrides from Gitlab::CurrentSettings
• Even though it is not actually used anywhere by remote development, it is a simple value from Gitlab::CurrentSettings that we can use to drive the behavior of reading settings overrides from Gitlab::CurrentSettings
• There are no current Gitlab::CurrentSettings entries for Remote Development, so we are using this as an example. It can be easily deleted and replaced with one that is actually used by Remote Development once one exists.
• Otherwise, we would have to wait until one exists to implement this support.

project_cloner_image_name and project_cloner_image_tag are a good choice because:

• They are settings which were originally requested to be configurable by a community contributor in Allow images to be specified by ENV variables (!134984 - closed), and motivated us to introduce this module
• They show an example of injecting settings into the Remote Development Domain Logic layer in a decoupled way via the Railway Oriented Programming.

Acceptance Criteria

• Implement module with initial examples.
• Decide if this should incorporate precedence/override behavior for settings from the specified devfile or GitLab Agent for Kubernetes agent configuration file.
  • ANSWER: No, I don't think this makes sense, it doesn't seem like it belongs as part of this module. If someone else feels we should look into it, we can.

Technical Requirements

See developer documentation additions in the MR to ee/lib/remote_development/README.md for details.

Note that this is intentionally decoupled from the rest of the Remote Development domain logic, to avoid introducing circular dependencies when it is used in multiple locations.

This updated architecture diagram from the MR shows the dependency structure:

Design Requirements

No design involved.

Impact Assessment

Provide a cohesive and standardized way to handle all configuration/settings across the Remote Development domain.

This will make all future settings easier and lower-risk to implement.