MR: Pending <!-- The first line of this issue description must be one of the following: 1. `MR: Pending` 2. `MR: <MR link with trailing +>`, 3. If there are multiple MRs: ``` MRs: - <MR 1 link with trailing +>` - <MR 2 link with trailing +>` - ... ``` 4. `MR: No MR` ...and the first description line of the MR should be `Issue: <Issue link with trailing +>` For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/index.html#relationship-of-issues-to-mrs --> <!-- The following sections should be filled out as part of the refinement process before the issue is prioritized. For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#2-pre-iteration-planning-meeting --> ## Description Raised from this comment: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/166343#note_2121149217 The ROP settings module contains some validation logic that is a duplicate of what is already present on DB models. Currently, these settings are only configurable via defaults/env overrides(only in the development environment) which we can make sure ourselves are correct. This means the validations do not provide any benefit and just increase maintenance costs. When we plan on working on the settings module, we should look into leveraging the existing db validations that may exist for some of these values rather than duplicating the logic. ## Acceptance Criteria - [ ] Cleanup redundant validation from the settings module <!-- Replace with other type, e.g. bug or maintenance, if appropriate --> <!-- Replace with other subtype if appropriate --> <!-- By default, all issues start in the unprioritized status. See https://handbook.gitlab.com/handbook/engineering/development/dev/create/remote-development/#-planning-process --> <!-- For simplicity and to avoid triage bot warnings about missing workflow labels, we will default to issues starting at the refinement phase -->