feat: implement REST-based collector for ONTAP

[vgratian]

I recently pushed a branch where I prototyped a REST-collector for ONTAP. Here is an overview and a few issues that I would like to discuss.

Overview

The general logic of the collector is very similar to our current Zapi-collector:

• Each REST path (e.g. storage/disks) is treated as an "object"
• Each path/object has a set of counters that the user wants to collect, defined in a subtemplate (example)
• The subtemplate defines type of each counter: the collector itself does not perform type-checking
• Counters are collected and submitted as they are, no post-processing or delta-calculation is done (unless we use plugins)
• Anything else is exactly as the other collectors

Open Issues (feedback would be appreciated)

Templating DSL

The set of counters and their types are defined in the subsection counters of each subtemplate. A few things are different from what we had before in Zapi:

• Instead of the XML-like tree structure, we have dot-separated paths (e.g. node.uuid means "uuid" is child attribute of "node").
• The ? meta-character means that counter type is boolean. The ^, ^^ and => meta-symbols have the same function as before.

Auxiliary polls

The Zapi-collector performs 2 polls: one to collect data and one to update its instance cache. In my POC this is not implemented yet. Open question is weather we should do this in a separate poll (as in Zapi), or jointly during the data poll (computationally expensive, but simplifies code a lot).

The ZapiPerf-collector also has a 3rd poll to update counter metadata. This is relatively easy, since the zapiperf APIs provide detailed metadata for each counter. This makes the code a bit more complex, but the ZapiPerf collector is much better at handling inaccuracies in templates or change of counter properties after ONTAP upgrade. Open question is weather (at some point) we want a similar mechanism in the REST collector as well. We could use the same swagger-parsing feature of the Rest-tool for this end.

REST-client

The client implementations of the Rest-tool and the POC should be merged into one package, just like the Zapi client.

[ruanruijuan]

related issue #59.

[cdurai-netapp]

we have observed following issues but they are not show stopper. will discuss with team and raise a new issue if required.