Add virtual machine templates count to common report "trailer", metrics?

[atc0005]

Overview

The report "trailer" currently emits details similar to this for plugins which offer filtering of virtual machines, folders, etc.:

* vSphere environment: https://vc1.example.com:443/sdk
* Plugin User Agent: check-vmware/v0.35.0
* VMs evaluated: 491 of 492
* Powered off VMs evaluated: true
* Specified VMs to exclude (1): [vm1]
* Specified Folders to explicitly include (0): []
* Specified Folders to explicitly exclude (0): []
* Folders evaluated: 0 of 144
* Specified Resource Pools to explicitly include (0): []
* Specified Resource Pools to explicitly exclude (0): []
* Resource Pools evaluated (30 of 30): [rp1, rp2, ..., rp29]

Would it be useful to also include a line similar to the following?

...
* VM templates evaluated: X of Y

X in this case would usually be 0, Y would be whatever number of templates are in the inventory.

I initially thought "no" and am still leaning this direction as:

• the trailer is already fairly dense and likely to grow based on other filtering options included in the future
• no plugins currently provided by this project include/exclude VMs based on whether they're a template vs a "normal" VM

The same goes for a perfdata metric.

Filing this for further consideration, but as of now I think it's better to hold off listing those details (trailer, metric) until #879 is implemented.

References

• Add support for excluding/ignoring VMs by Folder Managed Object ID (MOID) #809
• Create plugin to monitor age of VM templates #879

[atc0005]

As the OP indicates, this was something I had prototyped for #809 but ultimately decided against it for two reasons:

• The implementation for gathering the details was too slow
• I could not find a legitimate/useful reason for emitting the number of templates in the inventory

The first was the primary reason as I believe I could have made listing the template count work without being too dense (the scope of this GH issue).

I ultimately could not justify the change as it increased the runtime of applicable plugins too much. With some refactoring work (see also #926) this cost may not be as significant as it seemed during initial prototyping work.