All remote_development_agent_configs table fields should be nullable

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

UPDATE: This issue should not be necessary if we do the conversion of these fields as part of Switch from remote_development_agent_configs ta... (#480135 - closed). So we are keeping it around for context, but marking it blocked on that issue, and we can just close it once it's done.

Description

All remote_development_agent_configs table fields should be nullable.

• 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

• All remote_development_agent_configs table fields are nullable.

Technical Requirements

• This is necessary in order to have a concept of "undefined" for Agent-level settings.
• It will be necessary once we add the AgentConfigSettings step to the Workspaces Settings Module ROP chain.
• DB migrations can be normal migrations - we do not have the data volume to justify background migrations.
• We also need to change ee/lib/remote_development/agent_config/updater.rb to only write to the fields in the table if they are actually defined in the agent config file
• There should be NO changes needed to the golang or protobuf code to allow null values.
• QUESTION: Do we need special handling for the enabled field? Or can we handle it like all other fields - including allowing it to be locked/overridden in the future at the CascadingSettings instance/namespace/project level? Or should it be a special case behavior where it can be overridden, and can be locked to false, but cannot be locked to enabled, because we always want the agent admin to be able to force disabling of usage of the associated cluster?

Design Requirements