Port cibadmin gatherer

[arbulu89]

cibadmin gatherer. It tranfsorms the xml output of cibadmin command and it converts it to a map, so we can access all the fields.
As xml->json transformation cannot be done without having real xml struct domain data, I needed to transform some well done values always to list (primitive, master, etc). These values are lists, but the mxj cannot know that, if we only have 1 entry. That's why we convert them.

Usage:

./trento-agent facts gather --gatherer cibadmin --argument cib.configuration.resources.master.primitive.instance_attributes.nvpair.0.value

...

INFO[2022-12-02 12:31:53] Gathered fact for "cibadmin" with argument "cib.configuration.resources.master.0.primitive.0.instance_attributes.nvpair.0.value": 
INFO[2022-12-02 12:31:53] {
  "Name": "cib.configuration.resources.master.0.primitive.0.instance_attributes.nvpair.0.value",
  "CheckID": "",
  "Value": {
    "Value": "PRD"
  },
  "Error": null
}

[nelsonkopliku]

Looks good to me.

The only doubt that I have is that current checks are using cibadmin -Q --xpath WHATEVER rather than cibadmin --query --local.
Maybe they are the same, or we can achieve the same result, and I am missing something, though 😅

[dottorblaster]

@CDimonaco are you aware of some other way to declare this stuff both cleanly and without pissing off the linter? I don't like globals, but I have to say I like what @arbulu89 did here.

[arbulu89]

In any case, is not something I made up here. We have been using this way in all the gatherers since we started the porting

[arbulu89]

@nelsonkopliku

The only doubt that I have is that current checks are using cibadmin -Q --xpath WHATEVER rather than cibadmin --query --local.

This is because we won't use xpath anymore. xpath is used to get specific values from a xml, but now, as the code converts the xml to a map, we can access it with the normal dot access way. xpath has some limitations to get complex values and it would be not usable in rhai.
I will document it in the gatherers docs.

About the local, is is a common thing to do when you are simply querying things in the local node.

[arbulu89]

Hey @fabriziosestito ,
I have done the NewFactValue more robust now. Based on: https://github.com/protocolbuffers/protobuf-go/blob/6875c3d7242d1a3db910ce8a504f124cb840c23a/types/known/structpb/struct.pb.go#L316

You can actually put many entries in the same case line

[arbulu89]

As an improvement of the casting to string the next code would work:

        case bool:
		return &FactValueBool{Value: value}, nil
	case int:
		return &FactValueInt{Value: value}, nil
	case int32:
		return &FactValueInt{Value: int(value)}, nil
	case int64:
		return &FactValueInt{Value: int(value)}, nil
	case uint:
		return &FactValueInt{Value: int(value)}, nil
	case uint32:
		return &FactValueInt{Value: int(value)}, nil
	case uint64:
		return &FactValueInt{Value: int(value)}, nil
	case float32:
		return &FactValueFloat{Value: float64(value)}, nil
	case float64:
		return &FactValueFloat{Value: value}, nil
	case string:
		return ParseStringToFactValue(value), nil

But in the current scenario I prefer a bit less efficient code which is easier to follow.
We can change it the future if we need more customized conversion