[9.4](backport #6829) fix: report server capabilities in OpAMP responses

[mergify]

What is the problem this PR solves?

The OpAMP spec requires the server to report its capabilities bitmask in the first ServerToAgent response. Fleet-server was not setting this field, so agents could not discover what the server supports.

How does this PR solve the problem?

Send the serverCapabilities bitmask (AcceptsStatus, AcceptsEffectiveConfig) in the ServerToAgent response when an agent enrolls or reconnects from a non-active status (offline, disconnected). Active agents (online, error, degraded) do not receive capabilities on every message to reduce response size. An isActiveStatus helper determines which statuses are considered active.

Design Checklist

• I have ensured my design is stateless and will work when multiple fleet-server instances are behind a load balancer.
• I have or intend to scale test my changes, ensuring it will work reliably with 100K+ agents connected.
• I have included fail safe mechanisms to limit the load on fleet-server: rate limiting, circuit breakers, caching, load shedding, etc.

Checklist

• I have made corresponding changes to the documentation
• 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

Related issues

• Closes [OpAMP] fleet-server should send capabilites #6785

  ---

  This is an automatic backport of pull request fix: report server capabilities in OpAMP responses #6829 done by Mergify.

[mergify]

Cherry-pick of bc20c8b has failed:

On branch mergify/bp/9.4/pr-6829
Your branch is up to date with 'origin/9.4'.

You are currently cherry-picking commit bc20c8b.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Changes to be committed:
	new file:   changelog/fragments/1776103950-report-opamp-server-capabilities.yaml
	modified:   internal/pkg/api/openapi.gen.go
	modified:   model/openapi.yml
	modified:   pkg/api/types.gen.go

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   docs/opamp.md
	both modified:   internal/pkg/api/handleOpAMP.go
	both modified:   internal/pkg/api/handleOpAMP_test.go

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

[github-actions]

🔍 Preview links for changed docs

• docs/opamp.md

[github-actions]

Vale Linting Results

Summary: 2 errors, 1 warning, 1 suggestion found

❌ Errors (2)

File	Line	Rule	Message
docs/opamp.md	3	Elastic.ConflictMarkers	Do not commit Git merge conflict markers in source code.
docs/opamp.md	4	Elastic.ConflictMarkers	Do not commit Git merge conflict markers in source code.

⚠️ Warnings (1)

File	Line	Rule	Message
docs/opamp.md	35	Elastic.Latinisms	Latin terms and abbreviations are a common source of confusion. Use 'for example' instead of 'e.g'.

💡 Suggestions (1)

File	Line	Rule	Message
docs/opamp.md	15	Elastic.Ellipses	In general, don't use an ellipsis.

---

The Vale linter checks documentation changes against the Elastic Docs style guide.

To use Vale locally or report issues, refer to Elastic style guide for Vale.

[macroscopeapp]

🔴 Critical api/handleOpAMP.go:38

Unresolved git merge conflict markers (<<<<<<< HEAD, =======, >>>>>>> bc20c8b) at lines 38-45 will cause a compilation failure. The Go compiler cannot parse these conflict markers as valid syntax. Resolve the conflict by keeping the server capabilities constant and the AgentDisconnect handling logic from the incoming change.

-<<<<<<< HEAD
-	kOpAMPMod = "opAMP"
-=======
 	kOpAMPMod          = "opAMP"
 	serverCapabilities = uint64(protobufs.ServerCapabilities_ServerCapabilities_AcceptsStatus |
 		protobufs.ServerCapabilities_ServerCapabilities_AcceptsEffectiveConfig)
->>>>>>> bc20c8b (fix: report server capabilities in OpAMP responses (#6829))

Also found in 1 other location(s)

docs/opamp.md:3

Unresolved git merge conflict markers are being committed to docs/opamp.md. Lines 3 (<<<<<<< HEAD), 4 (=======), and 59 (>>>>>>> bc20c8b (fix: report server capabilities in OpAMP responses (#6829))) contain conflict markers that should have been resolved before committing. This will render the documentation malformed and confusing to users viewing the file.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file internal/pkg/api/handleOpAMP.go around lines 38-45:

Unresolved git merge conflict markers (`<<<<<<< HEAD`, `=======`, `>>>>>>> bc20c8b`) at lines 38-45 will cause a compilation failure. The Go compiler cannot parse these conflict markers as valid syntax. Resolve the conflict by keeping the server capabilities constant and the `AgentDisconnect` handling logic from the incoming change.

Evidence trail:
File: internal/pkg/api/handleOpAMP.go, lines 38-43 (viewed at REVIEWED_COMMIT). The conflict markers `<<<<<<< HEAD`, `=======`, and `>>>>>>> bc20c8b` are present in the const block, which will cause Go compilation failure.

Also found in 1 other location(s):
- docs/opamp.md:3 -- Unresolved git merge conflict markers are being committed to `docs/opamp.md`. Lines 3 (`<<<<<<< HEAD`), 4 (`=======`), and 59 (`>>>>>>> bc20c8b (fix: report server capabilities in OpAMP responses (#6829))`) contain conflict markers that should have been resolved before committing. This will render the documentation malformed and confusing to users viewing the file.

[mergify]

This pull request is now in conflicts. Could you fix it @mergify[bot]? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b mergify/bp/9.4/pr-6829 upstream/mergify/bp/9.4/pr-6829
git merge upstream/9.4
git push upstream mergify/bp/9.4/pr-6829