Add support for "locked" attribute to Settings Module

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Work on this issue
• Close this issue

MR: Pending

Description

Add support for "locked" attribute to Settings Module

• See Workspaces Settings Configuration Infrastructur... (&14186) for overview and more context
• See Related Issues and MRs section in that epic for related issues and MRs

Acceptance Criteria

• Adds support for "locked" attribute to Settings Module
• Update integration tests for settings module.
• Updates docs for settings module

Technical Requirements

• This is necessary to pass the locked attribute in the Settings Module along the ROP chain, so that later/subsequent/lower-precedence steps can be ignored/short-circuited if it the setting was locked by a previous step.
• This support should be back-ported into lib/gitlab/fp/settings/default_settings_parser.rb, and the return value of that should probably be changed from a tuple into a hash of value, type and locked for clarity. This return value API change will also have to be reflected in both the Web IDE and Workspaces usage of lib/gitlab/fp/settings/default_settings_parser.rb
• The Web IDE Settings Module does NOT need to use this value yet.
• The Workspaces Settings module will use this in lib/remote_development/settings/current_settings_reader.rb as well as the agent setting step, by simply adding an additional guard clause to check the locked status for each setting in the loop. This will establish the pattern for handling the locked attribute in the future when we add additional steps to the chain.
• The EnvVarOverrideProcessor step will NOT observe the locked attribute. The docs for the Settings Module should be updated to reflect this.

Design Requirements