Explicitly set fields while responding from agentk to rails
<!--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=409133)
- [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=409133)
</details>
<!--IssueSummary end-->
MR: Pending
<!--
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
### What
All fields sent from agentk to rails in the reconciliation request payload should be included, even if they are explicitly null or an empty array/object.
Similar to https://gitlab.com/gitlab-org/gitlab/-/issues/406261+ (which I think we have already addressed on Rails and can be closed)
When agentk sends information to Rails, it sends the following fields
```go
type WorkspaceAgentInfo struct {
Name string `json:"name"`
Namespace string `json:"namespace,omitempty"`
LatestK8sDeploymentInfo map[string]interface{} `json:"latest_k8s_deployment_info,omitempty"`
TerminationProgress TerminationProgress `json:"termination_progress,omitempty"`
}
```
We always send the `Name`. Everything else is not always sent. This makes it annoying to understand when a field would be present in information received by Rails from agentk. We should ensure all fields are explicitly sent all times with configured defaults.
### How
AFAIK, we only generate the information we need to send to Rails in the function `generateWorkspaceAgentInfos`
1. For workspaces that are recently updated in the cluster and agentk has received information about it, we are not sending `TerminationProgress`. Let's send that with an `NotApplicable` value. In the future, we can add parameter validation on Rails.
2. For workspaces that are `Terminating`/`Terminated`, we are not sending `Namespace` and `LatestK8sDeploymentInfo`. For `LatestK8sDeploymentInfo`, let's send a `nil` or empty map. Also, send the `Namespace` in this case as well.
### Why sending namespace is important
Assume you have created a workspace called `example-workspace` in namespace `example-ns`. Now when we are sending information about the workspaces to rails and skip the namespace, it can be problematic and a bad actor can mess up our logic.
Imagine the user creating a deployment called `example-workspace` with the exact same configuration as the above workspace in their namespace (let's say `personal-ns`). The informer will catch this and send us this information. This would start messing up the state of the workspace in our Postgres DB because we would be tracking the details of the `example-workspace` in the namespace `personal-ns`.
### Followups
On the rails side, while querying a workspace in the DB, we'll use both the name and the namespace. This will ensure we are always updating the right workspace even if there are any kind of malicious/unwarranted instances from the user having access to the kubernetes cluster.
### Update:
With https://gitlab.com/gitlab-org/gitlab/-/issues/409806, changes will be made to set namespace when terminating workspaces. Since this issue is bigger in scope and the rest of the requirements are of lower prioirty, it will picked up later in the future
## Acceptance Criteria
- [ ] All fields sent from the agent to rails in the reconciliation request should be explicitly set.
<!-- 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