Add new /_security/stats endpoint

[szybia]

• Add /_security/stats endpoint with skeleton body:

{
  "nodes": {
    "80M94RoASGqYcyRa7GI7gQ": {},
    "iQqwop8VTNS5YM_HLcgXEw": {},
    "g-90TEEpTpSZ7xFcLryUKA": {}
  }
}

• Shouldn't be contentious, extensible to whatever we decide in future PRs in regards to body structure and extra sub-endpoints
• First time adding an endpoint, so more in-depth review would be appreciated
• Adding DLS cache stats should be as easy as: c97e7b5, which would yield:

{
  "nodes": {
    "UvzwIk80R0OO5WiEoiWFIQ": {
      "roles": {
        "file": {
          "remote_indices": 0,
          "dls": false,
          "size": 1,
          "fls": false,
          "remote_cluster": 0
        },
        "native": {
          "remote_indices": 0,
          "dls": false,
          "size": 0,
          "fls": false,
          "remote_cluster": 0
        },
        "dls": {
          "bit_set_cache": {
            "count": 0,
            "memory": "0b",
            "memory_in_bytes": 0,
            "hits": 0,
            "misses": 0,
            "evictions": 0,
            "hits_time_in_millis": 0,
            "misses_time_in_millis": 0
          }
        }
      }
    }
  }
}

[elasticsearchmachine]

Hi @szybia, I've created a changelog YAML for you.

[elasticsearchmachine]

Pinging @elastic/es-security (Team:Security)

[tvernum]

At a high level this looks good to me.

I let @joegallo review the minute details like the NodeFeature, etc but the URI, response shape, etc all look right to me.

[joegallo]

I'm not sure how we typically handle a new transport actions and mixed mode clusters during upgrade. It seems like things wouldn't be happy if you have a pre-whatever cluster and one single node that's been upgraded to have this code, and then you hit the GET _security/stats endpoint on that one upgraded node. Perhaps the feature should be used to guard some of this? I'm not sure if we typically handle that scenario or not.

edit: a little birdie told me:

Yeah you need to make it a org.elasticsearch.features.NodeFeature and then use the Predicate<NodeFeature> clusterSupportsFeature parameter passed to ActionPlugin#getRestHandlers to determine whether the cluster supports the API or not.

It should also be a new transport protocol version, with something in GetSecurityStatsNodeRequest#writeTo which throws an UnsupportedOperationException if the transport version is too old.

[joegallo]

LGTM -- I kicked off one more run of CI since the last successful one was from Friday, but once that lands I think we're good to go. 👍