Remove `node` and `id` from list task response

[nik9000]

Right now the list tasks response returns both a node (string) and an id (number). The trouble is that everywhere else we refer to the task id as a string. The fact that the list tasks response has both of these elements implies some contract for the shape of a task id when we do not intend for there to be one. Currently the task id consists of the node, a :, and then the id but we might change it in the future without any prior warning.

I think we should remove node and id from the lists tasks response entirely and users should use the object's name in the response as the id.

This is what the response looks like now:

{
    "nodes": {
        "NCvmGYS-RsW2X8JxEYumgA": {
            "name": "NCvmGYS",
            "transport_address": "127.0.0.1:9300",
            "host": "127.0.0.1",
            "ip": "127.0.0.1:9300",
            "roles": [
                "master",
                "data",
                "ingest"
            ],
            "tasks": {
                "NCvmGYS-RsW2X8JxEYumgA:1204320": {
                    "node": "NCvmGYS-RsW2X8JxEYumgA",
                    "id": 1204320,
                    "type": "transport",
                    "action": "indices:data/write/delete/byquery",
                    "start_time_in_millis": 1528310404882,
                    "running_time_in_nanos": 24218556132,
                    "cancellable": true
                }
            }
        }
    }
}

And I want it to be:

{
    "nodes": {
        "NCvmGYS-RsW2X8JxEYumgA": {
            "name": "NCvmGYS",
            "transport_address": "127.0.0.1:9300",
            "host": "127.0.0.1",
            "ip": "127.0.0.1:9300",
            "roles": [
                "master",
                "data",
                "ingest"
            ],
            "tasks": {
                "NCvmGYS-RsW2X8JxEYumgA:1204320": {
                    "type": "transport",
                    "action": "indices:data/write/delete/byquery",
                    "start_time_in_millis": 1528310404882,
                    "running_time_in_nanos": 24218556132,
                    "cancellable": true
                }
            }
        }
    }
}

[elasticmachine]

Pinging @elastic/es-distributed

[diaojinggang]

When we designed the response format in the very beginning. Why don't we use a format like this? Give node_id and task_id proper keys.

{
    "nodes": [
         {  "node_id" : "NCvmGYS-RsW2X8JxEYumgA",
            "name": "NCvmGYS",
            "transport_address": "127.0.0.1:9300",
            "host": "127.0.0.1",
            "ip": "127.0.0.1:9300",
            "roles": [
                "master",
                "data",
                "ingest"
            ],
            "tasks": [
                {   "task_id": "NCvmGYS-RsW2X8JxEYumgA:1204320",
                    "type": "transport",
                    "action": "indices:data/write/delete/byquery",
                    "start_time_in_millis": 1528310404882,
                    "running_time_in_nanos": 24218556132,
                    "cancellable": true
                }
            ]
        }
    ]
}

My use case was I need to extract the task_id "NCvmGYS-RsW2X8JxEYumgA:1204320". But there is no key for `"NCvmGYS-RsW2X8JxEYumgA:1204320". It took me extra five minutes to figure out how to extract that info without a key-value pair format. It's not a big deal but I am curious why we did not use the key-value format when we designed it? Just to save space?

[nik9000]

The task id is meant to be an implementation detail. We can change how they are formed at any time so long as the old versions of Elasticsearch continue to route the task fetch requests to the right node. We have no plans to change it but we wanted to keep our options open.

[DaveCTurner]

I have marked this as team-discuss because I think it is a good idea and want to discuss with the team how we should approach this while preserving BWC.

[DaveCTurner]

We continue to think this is a good idea, but the BWC issues make it tricky right now. However, we are forming a more general plan around breaking changes to response formats like this, and think that this work will let us address exactly this issue. Marking this as stalled until that work lands.