Fleet client configuration validation should take http status code into account

[pchila]

When elastic agent receives new fleet client configuration (hosts, proxy, CAs, certificates etc.) via Fleet policy, it performs a connection check using the new parameters to ensure that applying the new configuration would not result in loss of connectivity to Fleet, leaving the agent unable to receive any more policy updates.

While developing tests for #4770 , due to a misconfiguration of the proxy the connection check succeeded even if the http status code returned 500 - Internal server error resulting in a broken configuration to be applied and used by elastic-agent (the underlying connection worked fine and that is all that is checked).
Although it was just a misconfigured test, this is a real case that can happen in production when switching to a badly configured proxy/fleet server and it would still result in agent being unable to check in correctly.

The goal of this issue is to add a check on the http status code on top of just checking for connection errors as we already do today.

[elasticmachine]

Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)

[elasticmachine]

Pinging @elastic/elastic-agent (Team:Elastic-Agent)

[pchila]

An example of implementation can be seen in draft PR #4905

[pchila]

/cc @ycombinator @cmacknz @AndersonQ

[amitkanfer]

good catch @pchila