Processor add_cloud_metadata adds incorrect values to cloud metadata fields

When running elastic stack on self-managed on-prem cluster (100% of their Windows hosts are physical, on-prem machines), a large volume of the ingested logs contain `cloud.*` fields. This is unexpected since none of these hosts are cloud VMs.
For example:
```
cloud.provider: openstack
cloud.service.name: Nova
```

This issue is caused by the request that checks if the agent is running on AWS (169.254.169.254) being intercepted by a possible Fortinet firewall. Instead of timing out as it should if it is not an AWS host, it returns an HTML redirect, which prevents the agent from running a proper check. Because of this incorrect response, the agent mistakenly sets the host's cloud provider to `openstack`.

```
window.location=\"https://169.254.169.254:80/fgtauth?000110ab149ec7aa\";
```

Instead of populating the cloud fields with the response of a firewall, `add_cloud_metadata` processor should verify the response from the endpoints first.

Start at the add_cloud_metadata processor and its AWS metadata endpoint check, then inspect how intercepted HTML responses are handled. Reproduce the Fortinet-style redirect response and verify that invalid endpoint responses no longer populate cloud fields; add or update coverage for this behavior.

Written by the indexing model from the issue text.