Add support for opensearch searchable snapshot metrics

[etgraylog]

Description

Elasticsearch & Opensearch both have a Searchable Snapshots feature that emit metrics from unique API endpoints:

• https://www.elastic.co/guide/en/elasticsearch/reference/current/searchable-snapshots-api-stats.html (introduced in 7.10)
• [Searchable Snapshot] Define additional metrics needed for searchable snapshots opensearch-project/OpenSearch#4968 (introduced in 2.7.0)

The Elasticsearch Searchable Snapshots metrics appear to be available via the es.snapshots argument, while there does not yet appear to be a similar argument for Opensearch Searchable Snapshot metrics.

A minimal amount of changes were realized to add support for these metrics, leveraging existing structs & other data types with a new node role while adding necessary elements to for example nodeMetrics (collector/nodes.go).

Motivation and Context

The motivation of this PR is to add support for Opensearch Searchable Snapshots to the elasticsearch_exporter so that they can be scraped by Prometheus for monitoring & serviceability.

Several modifications have been made in a fork to quickly add support for these. A better way to emit these more than likely exists so that for example only nodes with es_search_node=true would be collected. Moreover, adding a CLI argument to enable these metrics as they are not applicable to Elasticsearch. The changes in this PR could be a decent starting place however if not at least found useful by others.

Details

The proposed changes add 8x new metrics to the collection from the Opensearch Nodes API:

Metric name	Metric type
elasticsearch_filecache_active_in_bytes	Gauge
elasticsearch_filecache_active_percent	Gauge
elasticsearch_filecache_evictions_in_bytes	Gauge
elasticsearch_filecache_hit_count	Gauge
elasticsearch_filecache_miss_count	Gauge
elasticsearch_filecache_total_in_bytes	Gauge
elasticsearch_filecache_used_in_bytes	Gauge
elasticsearch_filecache_used_percent	Gauge

[mnin]

@sysadmind is there anything missing in this PR to review and merge it?

[etgraylog]

Perhaps this enhancement can be attempted again in a new Pull-request, but the commit history at this point from unsigned commits causing failed attempts to rebase I think is unacceptable.

[sysadmind]

I think that the branch needs to be rebased. It shouldn't be 72 commits. I would think it should be more like 1 or 2 commits depending on the complexity. There's a lot in here that isn't actually this change. A git rebase should fix that.