Add required API calls to retrieve configuration from Fleet.

[ph]

Kibana implement is in elastic/kibana#51968

--

This PR implements the required structs and calls to retrieve the
configuration from Fleet. This is step one before refactoring the
Reporter to split the pushing event and fetching of configuration.

[ph]

@nchaulet Did we remove success from the fleet checkin response? I though all endpoints response was returning that field? But looking at your comments in elastic/kibana#51968 this doens't appear to be the case?

[nchaulet]

No it's not removed it's here, I just did not put it in the examples.

[nchaulet]

@ph Currently every events need to have a type and a subtype it's why ACTION_ACKNOWLEDGE it implemented like event {type: 'ACTION', subtype: 'ACKNOWLEDGE'}

Do you think it's better to keep it like this or to make subtype optional and have {type: 'ACTION_ACKNOWLEDGE'} {type: 'ACTION_UNKNOWN'} ? I thinks the second option is less easier to understand.

Also I am going to document that when we have a decision

[michalpristas]

Looks good, thanks PH

[michalpristas]

i wonder if it's not possible keep it as []Action and make decisions based on ActionType. Lazy casting basically

[ph]

Yeah, I had mixed feeling went implementing this, I had two ideas:

1. Make it generic, extract the minimal required fields for the action ( type / action ID) and puts everything else in a json.RawMessage field so it can be lazily extracted later one.
2. Implement a base type + concrete type on top of it.

I've gone with the second option because I wanted to keep the serialization in a single place and theses are just data object no logic should be added to them. If new behavior is required, we either:

1. Create a new type / type cast to a new type.
2. Create a function that accepts the struct.

Now, I diverge on that with the Event, as you may have noticed I've created a SerializableEvent interface that implements a minimum public interface and expect the user to correctly serialize the type to the JSON. I did this because, an event from Agent doesn't have at the moment a finite number of possibilities.

[ph]

@ph Currently every events need to have a type and a subtype it's why ACTION_ACKNOWLEDGE it implemented like event {type: 'ACTION', subtype: 'ACKNOWLEDGE'}

Do you think it's better to keep it like this or to make subtype optional and have {type: 'ACTION_ACKNOWLEDGE'} {type: 'ACTION_UNKNOWN'} ? I thinks the second option is less easier to understand.

@nchaulet I can do the type/subtype thing, I was following your example in the PR description in elastic/kibana#51968 (comment)

edit: the description was updated with the right return now.

[ph]

I've made the changes @nchaulet and @michalpristas:

• Fix the fields when acking an action.
• Prefixing the Action with "Action" instead of using a suffix this more inline with Error in golang and other system types.

[nchaulet]

Looks good to me, it should worked correctly with fleet API 👍