Have stats response include metadata about stats request

[bcorrie]

Need to ensure that the stats response has a tag in the response clarifying which stat request the response is for.

[bcorrie]

The current stats API has a "statistics_name" field that tells the client which stat the response is for, so I think this can be closed.

A stats result is essentially an array of objects of the following structure:

  "Result": [
    {
      "repertoire": {
        "repertoire_id": "REPID_4598",
        "sample_processing_id": "SPID_1",
        "data_processing_id": "DPID_1"
      },
      "statistics": [
        {
          "statistic_name": "statistic_name",
          "total": 30,
          "data": [
            {
              "key": "key",
              "count": 10
            }
          ]
        }
      ]
    }
  ]

[bcorrie]

@ajrocha @marcoamarooliveira I think this takes care of our first concern. If someone asked for v_call, v_gene, v_subgroup for this repertoire, they would get an array of three elements in "statistics": [], each tagged with "statistics_name":"v_call" etc.

We still need to have a mechanism that deals with the need to construct a hierarchical data structure based on the relationship `"v_call" -> "v_gene" -> "v_subgroup". But then the visualization simply takes in this hierarchical data structure and renders it - no domain knowledge required by the visualization...

Make sense?

[bcorrie]

This need is primarily around the interface between the Stats API and how clients use it and how our visualization library takes Stats info. In discussing with @marcoamarooliveira we decided that the visualization's domain knowledge middleware (the software that understands the hierarchy of subgroup -> gene -> allele) will handle only a single set of stats or a set of three (which will always consist of subgroup -> gene -> allele). The middleware will take this and build the hierarchical structure that the visualization requires to create a drilldown graph where required

So for now, we don't need metadata embedded in the response for now... I think this can be closed at least for our initial prototype for M24. @marcoamarooliveira @schristley @bzimonja @jeromejaglale any objections?

[bcorrie]

Closing - we can reopen if need be...