Just because we have an error connecting to the server doesn't mean the client's configuration is invalid. Callers can inspect the error we return and decide what to do with the returned client.

Not needed and easier to read when exposed in UI.

No relational databases or server-side dependencies required. Requires docs!

Used to document, explain stuff. Useful!

Documentation too. It's not quite clear enough that callers need to handle resubscribing on any errors reading the stream. It's documented for Subscribe but example usage would be good too.

On Debian 11 these fields are floats, not ints (or boolean) for some reason. This patch allows unmarshalling either floats or integers depending on what the icinga API sends us.

because there's so many subscribers... lol

Includes tests and simplified unmarshal test.

We don't need to have a MarshalJSON method just so that it can be created ok. It's clearer to do stuff necessart for object creation at the time of object creation, not way earlier in some unrelated bit of the code. While here simplify the tests to actually test what we're worried about.

We can test hostgroup assignment in other tests if desired.

No need for a file on disk; it's only referenced once.

On OpenBSD. Why not?

A lot of the testing doesn't really flex what a real icinga2 server does. We can implement a simple fake server with about 250 lines of Go, then we get all the benefits of really quick feedback and no dependency on an icinga2 server (which isn't super easy to set up) for most tests. More complicated tests are still performed against a real server listening on loopback (if available).

All this did was wrap the usual standard library JSON decode procedure.

We always returned something on the first iteration, so just remove it.

We're just in test mode, so it's ok to panic if we reach this highly unlikely scenario when, for example, the testdata file changes or something.

There's no point doing so much manual work and testing just to keep fields under a "attrs" key when marshalling to JSON. When creating the object we can just: 1. Marshal the object to JSON 2. Put it all under a "attrs" key. Now it's easier to imagine the mapping of the structs to JSON, since they follow the same rules as everything else in Go.

While here also don't log messages in testing unless there's an error.