Refactor: Use the capabilities to defined if an Agent is upgradable or not

[ph]

Today we can use https://github.com/elastic/beats/blob/64f70785c0911eeb6f3f6ce5264f61544844ca0f/x-pack/elastic-agent/pkg/agent/application/upgrade/upgrade.go#L78 to define if a release is upgradable or not. We have added the concept of capabilties in elastic/beats#23848

We should if to the capabitilies files, it could look like this:

capabilities:
-  upgrade: false

@ruflin @mostlyjason WDYT if make it generic on the action that we support https://github.com/elastic/beats/tree/1f1fae56057dce0604f72f2cf0099f9a6f2b75aa/x-pack/elastic-agent/pkg/agent/application/pipeline/actions/handlers?

capabilities:
- rule: deny
  action: Upgrade

[elasticmachine]

Pinging @elastic/agent (Team:Agent)

[ruflin]

++ on adding it to capabilities.

@ph Can you elaborate on the action approach? You mean it would cover multiple cases at once directly? If yes, kind of like the idea.

We will need to make sure independent of the implementation, that an Agent reports its capabilities so Fleet can disable certain UI components / API calls.

[ph]

@ruflin Yeah, This is my point, we could cover multiple cases with a single strategy. Every command send from Fleet is an action, including upgrade so if we add something to control which kind of action we can executed on the agent we actually support the current use case of an upgrade and any potential action we would like to restrict in the future.

And by doing so we only need to figure out "how capabilities" are surfaced back in the UI.

[blakerouse]

I think we should scope the action based on the input type and for elastic-agent use that for its type, so requiring all actions to have a prefix of {input-type}/{action-name}. So for the Elastic Agent it would look like?

capabilities:
- rule: deny
  action: elastic-agent/upgrade

That would allow actions targeting specific inputs to also be denied. Thoughts?