Support agent available rollback fields

[pchila]

What is the problem this PR solves?

This PR handles new available_rollbacks field sent by elastic-agent during checkin (implemented in PR elastic/elastic-agent#11143).
This information will be consumed by the Fleet UI to allow a manual rollback of recently upgraded agents.

How does this PR solve the problem?

This PR introduces new available_rollbacks field both in CheckinRequest and pendingT structs as a slice of AvailableRollbacks and a JSON array of objects respectively.

How to test this PR locally

Refer to PR elastic/elastic-agent#11143 How to test this PR locally section.

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 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

Related issues

• Relates Support manual rollback for Fleet-managed agents elastic-agent#11143

[michalpristas]

not sure this was RFCed but could this be part of upgrade meta? like scheduled_at or error_msg so we don't pollute root object with upgrade specific stuff?

[michalpristas]

i imagine you don't need this info outside of upgrade window anyways

[pchila]

Not sure if you are referring to the checkin request body, the validatedCheckin struct or the ES document structure.

The main reason that I didn't mix this information with existing upgrade stuff is that there are assumptions about upgrade details and I didn't know if there are more around other other upgrade fields.

The information about available rollbacks must survive beyond the duration of a single upgrade (and fleet detects the conclusion of an upgrade by the upgrade_details field disappearing in the checkin body) and it's also not a stable intrinsic characteristic of agent so that it can go in something like local_metadata.

The RFC will be updated with the final schema we are gonna have in this PR.