<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Work on this issue](https://contributors.gitlab.com/manage-issue?action=work&projectId=278964&issueIid=479702) - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=479702) </details> <!--IssueSummary end--> MR: Pending ## Description Add support for "locked" attribute to Settings Module - See https://gitlab.com/groups/gitlab-org/-/epics/14186+ for overview and more context - See [Related Issues and MRs section in that epic](https://gitlab.com/groups/gitlab-org/-/epics/14186#related-issues-and-mrs) 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