Backend: Add logic for saving agent configuration in DB
MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/138732+
<!--
The first line of the MR must be one of the following:
1. `MR: Pending`
2. `MR: <MR link with trailing +>`,
and the first description line of the MR should be `Issue: <Issue link with trailing +>`
3. `MR: No MR`
For more context, see:
https://about.gitlab.com/handbook/engineering/development/dev/create/ide/index.html#1-to-1-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
As a user, I want to be able to specify the default and max cpu/memory to be used for all workspaces provisioned through an agent.
```yaml
remote_development:
default_resources_per_workspace_container:
limits:
cpu: 1
memory: 500m
requests:
cpu: 500m
memory: 500Mi
max_resources_per_workspace:
limits:
cpu: 1
memory: 500Mi
requests:
cpu: 500m
memory: 500Mi
```
## Acceptance Criteria
- [x] All field for `default_resources_per_workspace_container` and `max_resources_per_workspace` are required.
- [x] The json structures should be validated with a new JSON schema as part of activerecord validation for the RemoteDevelopmentAgentConfig validation
- [x] Acceptable values for `cpu`/`memory` respect the format mentioned in https://kubernetes.io/docs/reference/kubernetes-api/common-definitions/quantity/ . The acceptable values would only be in string format as mentioned in https://gitlab.com/gitlab-org/gitlab/-/issues/427142#note_1685995949
- [x] Any changes to `default_resources_per_workspace_container` and `max_resources_per_workspace` are reflected in the DB if there are no validation errors.
- [x] If there are any validations errors, DB values will not get updated.
- [x] All non-terminated workspaces associated with the agent have `force_include_all_resources` set to `true`.
<!-- 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://about.gitlab.com/handbook/engineering/development/dev/create/ide/#-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 -->
issue