Provide better error messages on search request parse failures

We should strive to make error messages more actionable in case of parsing failures of a search request JSON. I know that pull parsing is making things harder here... Here are a few examples:

DELETE test

PUT test

GET test/_search
{
  "query": {
    "range": {
      "date": 
        "gte": "2015-06-20",
        "lte": "2015-09-22"
    }
  }
}

returns

{
  "error" : {
    "root_cause" : [
      {
        "type" : "parsing_exception",
        "reason" : "[range] query does not support [date]",
        "line" : 5,
        "col" : 9
      }
    ],
    "type" : "parsing_exception",
    "reason" : "[range] query does not support [date]",
    "line" : 5,
    "col" : 9
  },
  "status" : 400
}

This is invalid JSON (notice the missing opening { after "date":, however the error message hints at the fact, that the range query has an issue.

Second example, valid JSON, but not parseable, as the "type" field is not within the multi match query

DELETE test

PUT test

GET test/_search
{
  "query": {
    "multi_match": {
      "query": "party planning",
      "fields": [
        "headline",
        "short_description"
      ]
    },
    "type": "phrase"
  }
}

response

# GET test/_search
{
  "error" : {
    "root_cause" : [
      {
        "type" : "parsing_exception",
        "reason" : "[multi_match] malformed query, expected [END_OBJECT] but found [FIELD_NAME]",
        "line" : 10,
        "col" : 5
      }
    ],
    "type" : "parsing_exception",
    "reason" : "[multi_match] malformed query, expected [END_OBJECT] but found [FIELD_NAME]",
    "line" : 10,
    "col" : 5
  },
  "status" : 400
}

While technically correct, that the multi_match query should end, this error message does help any user, who is not aware of how JSON is parsed. You could mention, that the JSON should be closed, but element "type" was found instead or something.

And the last candidate, valid JSON, but invalid querying

DELETE test

PUT test
{
  "mappings": {
    "properties": {
      "my_field" : {
        "type": "keyword"
      }
    }
  }
}

GET test/_search
{
  "size": 0,
  "aggs": {
    "transactions_by_8_hrs": {
      "date_histogram": {
        "field": "my_field",
        "fixed_interval": "8h"
      }
    }
  }
}

returns

# GET test/_search
{
  "error" : {
    "root_cause" : [
      {
        "type" : "illegal_argument_exception",
        "reason" : "Field [my_field] of type [keyword] is not supported for aggregation [date_histogram]"
      }
    ],
    "type" : "search_phase_execution_exception",
    "reason" : "all shards failed",
    "phase" : "query",
    "grouped" : true,
    "failed_shards" : [
      {
        "shard" : 0,
        "index" : "test",
        "node" : "fZhL9ocFSr22NFU5D1G83A",
        "reason" : {
          "type" : "illegal_argument_exception",
          "reason" : "Field [my_field] of type [keyword] is not supported for aggregation [date_histogram]"
        }
      }
    ],
    "caused_by" : {
      "type" : "illegal_argument_exception",
      "reason" : "Field [my_field] of type [keyword] is not supported for aggregation [date_histogram]",
      "caused_by" : {
        "type" : "illegal_argument_exception",
        "reason" : "Field [my_field] of type [keyword] is not supported for aggregation [date_histogram]"
      }
    }
  },
  "status" : 400
}

The response is telling the user, that the field is not supported, but this is not actionable. How about returning what kind of fields are actually supported instead?