Fix indices.delete_alias response

[pquentin]

This regressed between March 25th and April 15th, back when recording examples wasn't stable. Unfortunately, 22 days worth of commits is a lot: elastic/elasticsearch@e9fcb0a...d3e0ec1. If we find where this is set, we could consider asking the Elasticsearch team to not do this. It's not helpful, as acknowledged is already set to true.

Another option: I could only change the delete_alias body instead of affecting all APIs that use AcknowledgedResponseBase.

[l-trotta]

I can't find this in the sever, AcknowledgeResponse only has one field. I think the problem is the fact that the body changes when there's an error, so for a normal response it's:

{
  "acknowledged": true
}

while when there's an error it's:

{
  "error": {
    "root_cause": [
      {
        "type": "illegal_argument_exception",
        "reason": "unable to put stored script with unsupported lang [painlesss]"
      }
    ],
    "type": "illegal_argument_exception",
    "reason": "unable to put stored script with unsupported lang [painlesss]"
  },
  "status": 400
}

in the spec we just map the first one, because the second case is the exception case (the server returns 404) so what java does is that it returns the error body in the exception message.

[pquentin]

Actually, we also get responses like this one:

{
  "api": "indices.delete_alias",
  "file": "/test/free/indices.delete_alias/all_path_options.yml",
  "name": "check delete with prefix* index",
  "origin": "yaml",
  "request": {
    "args": {
      "index": "test_*",
      "name": "alias1"
    }
  },
  "response": {
    "headers": {
      "content-encoding": "gzip",
      "content-length": "62",
      "content-type": "application/json",
      "x-elastic-product": "Elasticsearch"
    },
    "payload": {
      "acknowledged": true,
      "errors": false
    },
    "statusCode": 200
  }
}

[l-trotta]

ooh that's why: it's a subclass! we have to map this

[l-trotta]

update: it's more complex than it looks, I'm still working on this. in particular it seems like in case of error it can return detailed information, including a class that represents an ElasticsearchException which I don't think we already have.