Channel default value by changing default logic

[oxzi]

In a nutshell, the newly introduced plugin.PopulateDefaults function
populates all fields of a Plugin-implementing struct with those fields
from Info.ConfigAttributes where ConfigOption.Default is set. Thus, a
single function call before parsing the user-submitted configuration
within the Plugin.SetConfig method sets default values.

As a result of the discussion between the Go and the Web team,
summarized in #205, Web does not store key-value pairs to be omitted.

Prior, an already JSON-encoded version of the ConfigOption slice was
present in plugin.Info. Thus, this data wasn't easily available anymore.
As the new code now needs to access this field, it was changed and a
custom sql driver.Valuer was implemented for a slice type.

While working on this, all ConfigOptions were put in the same order as
the struct fields.

Requires Icinga/icinga-notifications-web#230.

Closes #205.

[yhabteab]

LFTM!

[oxzi]

Rebased after switch to icinga-go-library.

[julianbrost]

To avoid storing each default value twice, it's location was moved up to a "default" struct tag. By utilizing the already included defaults library and adding a small wrapper for plugin.Info, those defaults are now being set to the plugin.ConfigAttributes at runtime.

Have you considered doing it the other way around, i.e. applying the defaults from ConfigAttributes to the struct?

I think that this can be done in a much simpler way, without any custom use of reflection even: Iterate over ConfigAttributes and populate a map[string]any with the defaults (basically, you're already doing this, but it's more difficult to extract the information from the field tags). Then JSON-encode that map, in other words: generate a config like it would be written to the database when it would contain exactly the defaults. Then simply unmarshal it into the config struct before unmarshaling the config from the database.

[oxzi]

I liked @julianbrost's suggestion and worked on it. The new design reduces the change's size and is, imo, more readable. Please take another look.

[julianbrost]

Code change looks fine (and quite a lot nicer than the previous version IMHO), actually using default values by default sounds sane, did not break anything in my test setup including after saving the config from web again, so looks fine to me. Nonetheless, @yhabteab please also have another look at this as you were involved in the discussions mentioned in #205.

[yhabteab]

As a result of the discussion between the Go daemon team and the web
team, summarized in #205, web does not store or stores default values as
JSON "null" values. The Go JSON unmarshaller does not overwrite existing
field values for JSON nulls.

I'm a bit confused then, given that unmarshaling a JSON null value into a GO scalar type has no effect, how does the user clear optional default values then? Web does store null values to signify that a user does not want to use a default value of that field (if any). {"sender_name":"Foo","sender_mail":null,"host":"localhost","port":"25","encryption":"none"}

• a null value results in an empty value for optional key value pairs.

Or to be more specific, how do you deal with the second point of the referenced issue?

[oxzi]

For the record, as this changes the channel logic a bit and introduces another helper function, it should either be included in #236 if this got merged first or be an update in this PR otherwise.