Consider copying kubernetes.node.hostname to host.name

[ChrsMark]

Follow up of #22189 (comment)

We need to evaluate if kubernetes.node.hostname added at #22189 can be copied at host.name. Some testing need to take place in that case to verify that what is added is expected in that case as well what will happen if add_host_metadata is enabled at the same time.

Related to https://github.com/elastic/integrations-dev/issues/385, #20434

cc: @jsoriano @kaiyan-sheng @exekias

[elasticmachine]

Pinging @elastic/integrations-platforms (Team:Platforms)

[ChrsMark]

@jsoriano After reading #20434 again and running Metricbeat on GKE to test it I see the following:

It seems that kubernetes.node.name and host.name is the same while the kubernetes.node.hostname is actually different.

I guess that the main point of #20434 was to suggest using kubernetes.node.hostname in place of host.name (copy) as a more representative value, right? Just want to verify if this theory align with what we see in this example above?

[jsoriano]

Let's close this by now as it doesn't seem to be causing specific problems now, we can reopen later if we find specific use cases that need improvements.

[ChrsMark]

A note about ECS compatibility:

In this case, we can place the FQDN into host.name and use host.hostname for the value returned by hostname on the system (or returned from API).
Idea being that host.hostname represents what the server defines itself as but host.name is more of an accurate identity decided by the implementor. host.name is meant to only hold one value.

Leaving it here as reference for the future but we will need it to validate it again.