Allow updating dns_zone in remote development agent configuration

MR: feat: Allow for DNS Zone change in RD Config (!137277 - merged)

Problem to solve

As outlined in #395100 (comment 131800837), the configuration of an agent to support remote development is currently immutable. One of the properties which we do not allow to modify is

• dns_zone - This means that once dns zone is set, it cannot be updated at all. If anyone makes some mistakes, they can't fix it without decommissioning the agent and creating a new one. (This issue)

Proposal

• Allow users to update the dns_zone in the agent configuration.
• When the commit is made to the agent configuration
  • For the agent, update the dns_zone attribute in DB.
  • For all non-terminated workspaces of the agent, update the url attribute of the workspaces in the DB and set force_include_all_resources: true for such workspaces.
  • When the agent reconciles with Rails, it will receive updated details of the workspace(the generated Kubernetes resources will have updated host for the Ingress resource). Once agent applies them, the old URL of the workspace will no longer be accessible.

Cons

• No way to perform a phased "migration" of the workspace URL.

Other solutions considered

Make dns_zone a list

• Allow users to specify multiple dns_zones in the agent configuration.
  • Existing config is

    remote_development:
      dns_zone: x.y.z

  • New config would be

    remote_development:
      dns_zone:
      - a.b.c
      - x.y.z

• For all new workspaces, the first entry in dns_zone agent configuration would be used i.e. a.b.c.
• For all existing workspaces, if the DNS zone of the workspace URL is part of dns_zone agent configuration, it will continue as it is.
• For any existing workspaces, if the DNS zone of the workspace URL is NOT part of dns_zone agent configuration, the workspace URL would be updated to use the first entry dns_zone agent configuration i.e. a.b.c.
• Once user has completed the phased migration of the workspace URL, they can update the dns_zone to have only 1 entry.

  remote_development:
    dns_zone:
    - a.b.c

Cons

• Might be a little confusing to the end user. They might be under the impression that we can have workspaces with multiple different DNS zones for the same agent. Which is not the case - it would only be used for a "migration" in case someone wants to update their dns_zone.