Node Stats API broken in 7.15.0

[olivere]

Elasticsearch version (bin/elasticsearch --version):

Version: 7.15.0, Build: default/docker/79d65f6e357953a5b3cbcc5e2c7c21073d89aa29/2021-09-16T03:05:29.143308416Z, JVM: 16.0.2

Plugins installed: []

JVM version (java -version):

OS version (uname -a if on a Unix-like system):

Linux elasticsearch 5.10.47-linuxkit #1 SMP Sat Jul 3 21:51:47 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Description of the problem including expected versus actual behavior:

In #75433 you added a shard count structure to the Node Stats API. That results in a new JSON key named shards. However, if you run the Node Stats API with level=shards, you already have a JSON key named shards.

Steps to reproduce:

1. Run ES 7.15.0
2. Run curl -H 'Content-Type: application/json' -XGET 'http://localhost:9200/_nodes/stats?level=shards&human=true&pretty=true'
3. You will get two JSON keys named shards on the same level.

      ...
      "indices" : {
        "docs" : {
          "count" : 48,
          "deleted" : 0
        },
        "shards" : {                   // <-- 1st occurrence
          "total_count" : 2
        },
        ...
        "shards" : {                   // <-- 2nd occurrence
          ".tasks" : [
            {
              "0" : {
                "routing" : {
                  "state" : "STARTED",
                  "primary" : true,
                  "node" : "...",
                  "relocating_node" : null
                },
                "docs" : {
                  "count" : 5,
                  "deleted" : 0
                },
          "memory_size_in_bytes" : 0,
          "evictions" : 0
        },
        ...

Provide logs (if relevant):

[elasticmachine]

Pinging @elastic/es-data-management (Team:Data Management)

[DaveCTurner]

This is another instance of a more general testing problem (mentioned previously) that we appear to have no assertions to check that REST responses are well-formed representations of the claimed content-type.