Implement basic version negotiation with Fleet Server

[pchila]

What does this PR do?

We add an Elastic-Api-Version header to all requests to Fleet.
We already have support for detecting and logging warnings and downgrade requests (those are not yet implemented though)

The Warning header coming from Fleet is logged at fleet client level and propagated to coordinator via the specific error type WarningError. When the coordinator receives a WarningError will set fleet status to Degraded (as opposed to Failed that was used for any error up to this point) and set fleet status message to the warning it received.

Why is it important?

We aim for Elastic Agent to support connecting to multiple versions of Fleet server supporting multiple api versions.

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• [ ] I have made corresponding changes to the documentation
• [ ] I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• [ ] I have added an entry in ./changelog/fragments using the changelog tool
• [ ] I have added an integration test or an E2E test

Author's Checklist

• [ ]

How to test this PR locally

Related issues

Use cases

Screenshots

Logs

Questions to ask yourself

• How are we going to support this in production?
• How are we going to measure its adoption?
• How are we going to debug this?
• What are the metrics I should take care of?
• ...

[mergify]

This pull request does not have a backport label. Could you fix it @pchila? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-v./d./d./d is the label to automatically backport to the 8./d branch. /d is the digit

NOTE: backport-skip has been added to this pull request.

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2023-09-11T14:54:02.079+0000

• Duration: 28 min 25 sec

Test stats 🧪

Test	Results
Failed	0
Passed	6301
Skipped	59
Total	6360

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

• /package : Generate the packages.

• run integration tests : Run the Elastic Agent Integration tests.

• run end-to-end tests : Generate the packages and run the E2E Tests.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[elasticmachine]

🌐 Coverage report

Name	Metrics % (covered/total)	Diff
Packages	98.78% (81/82)	👍
Files	66.327% (195/294)	👍 0.115
Classes	65.751% (359/546)	👍 0.189
Methods	52.784% (1128/2137)	👍 0.158
Lines	38.287% (12815/33471)	👍 0.044
Conditionals	100.0% (0/0)	💚

[elasticmachine]

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

[elastic-sonarqube]

SonarQube Quality Gate

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

80.0% Coverage
0.0% Duplication

[joshdover]

@pchila Ideally we could backport this to the next 8.10.x patch. Any concerns with that?

[pchila]

@joshdover It shouldn't be too much of a risk since we only add a header, a couple of logs and an additional state to the fleet status in case of warning: nothing that should impact the core functionality of elastic-agent.
Just for completeness: should we backport #3394 as well ?

[joshdover]

Just for completeness: should we backport #3394 as well ?

See my comment here: #3362 (comment)

I actually think we might want to revert this as this scenario is not supported (users deploying their own Fleet Server against Serverless projects)

[ycombinator]

LGTM.