Standardize on params vs settings vs options

[bogdandrutu]

In few places for constructors we use "Params" (in the components), some "Parameters" (in the Service) or "Settings" in the components helpers like exporterhelper.

We need to decide on a name a pattern: expose a struct with these properties or expose "Options" and use variadic args.

Consolidate all interfaces to follow the same pattern.

[naseemkullah]

How about Config ? That is the term used by Zap: https://github.com/uber-go/zap/blob/89e382035d3a984a01e6c9c8be5462f11efac844/config.go#L58

[bogdandrutu]

@naseemkullah thanks for the suggestion, we use Settings the most, and probably to limit the amount of breaking changes we should stick with that.

Maybe we can look how many times we use each of them and make a decision. Config also has a problem because in our project Config is the file yaml config that we use to configure the entire service, and may be confusing for users.

[pmatyjasek-sumo]

Is someone working on this issue? If not I can do that

[tigrannajaryan]

Thanks @pmatyjasek-sumo, assigned to you.