Made all multi-bucket aggs return consistent response format

Closes #4926

docs/reference/search/aggregations/bucket/datehistogram-aggregation.asciidoc

@@ -111,7 +111,8 @@ Response:
 --------------------------------------------------
 {
     "aggregations": {
-        "articles_over_time": [
+        "articles_over_time": {
+            "buckets": [
                 {
                     "key_as_string": "2013-02-02",
                     "key": 1328140800000,
@@ -126,6 +127,7 @@ Response:
             ]
         }
     }
+}
 --------------------------------------------------
 
 Like with the normal <<search-aggregations-bucket-histogram-aggregation,histogram>>, both document level scripts and

docs/reference/search/aggregations/bucket/daterange-aggregation.asciidoc

@@ -34,7 +34,8 @@ Response:
     ...
 
     "aggregations": {
-        "range": [
+        "range": {
+            "buckets": [
                 {
                     "to": 1.3437792E+12,
                     "to_as_string": "08-2012",
@@ -48,6 +49,7 @@ Response:
             ]
         }
     }
+}
 --------------------------------------------------
 
 [[date-format-pattern]]

docs/reference/search/aggregations/bucket/geodistance-aggregation.asciidoc

@@ -28,7 +28,8 @@ Response:
 --------------------------------------------------
 {
     "aggregations": {
-        "rings": [
+        "rings" : {
+            "buckets": [
                 {
                     "unit": "km",
                     "to": 100.0,
@@ -48,6 +49,7 @@ Response:
             ]
         }
     }
+}
 --------------------------------------------------
 
 The specified field must be of type `geo_point` (which can only be set explicitly in the mappings). And it can also hold an array of `geo_point` fields, in which case all will be taken into account during aggregation. The origin point can accept all formats supported by the `geo_point` <<mapping-geo-point-type,type>>:

docs/reference/search/aggregations/bucket/histogram-aggregation.asciidoc

@@ -34,7 +34,8 @@ And the following may be the response:
 --------------------------------------------------
 {
     "aggregations": {
-        "prices": [
+        "prices" : {
+            "buckets": [
                 {
                     "key": 0,
                     "doc_count": 2
@@ -50,6 +51,7 @@ And the following may be the response:
             ]
         }
     }
+}
 --------------------------------------------------
 
 The response above shows that none of the aggregated products has a price that falls within the range of `[100 - 150)`. By default, the response will only contain the non-empty buckets, though it is possible to also return those, by setting the `empty_buckets` flag to `true`:
@@ -75,7 +77,8 @@ Response:
 --------------------------------------------------
 {
     "aggregations": {
-        "prices": [
+        "prices" : {
+            "buckets": [
                 {
                     "key": 0,
                     "doc_count": 2
@@ -95,6 +98,7 @@ Response:
             ]
         }
     }
+}
 --------------------------------------------------
 
 ==== Order
@@ -187,6 +191,7 @@ NOTE:   The special value `0` can be used to add empty buckets to the response b
 {
     "aggregations": {
         "prices": {
+            "buckets": {
                 "0": {
                     "key": 0,
                     "doc_count": 2
@@ -214,6 +219,7 @@ NOTE:   The special value `0` can be used to add empty buckets to the response b
             }
         }
    }
+}
 --------------------------------------------------
 
 ==== Response Format
@@ -242,6 +248,7 @@ Response:
 {
     "aggregations": {
         "prices": {
+            "buckets": {
                 "0": {
                     "key": 0,
                     "doc_count": 2
@@ -257,4 +264,5 @@ Response:
             }
         }
     }
+}
 --------------------------------------------------

docs/reference/search/aggregations/bucket/iprange-aggregation.asciidoc

@@ -30,7 +30,8 @@ Response:
     ...
 
     "aggregations": {
-        "ip_ranges": [
+        "ip_ranges":
+            "buckets" : [
                 {
                     "to": 167772165,
                     "to_as_string": "10.0.0.5",
@@ -44,6 +45,7 @@ Response:
             ]
         }
     }
+}
 --------------------------------------------------
 
 IP ranges can also be defined as CIDR masks:
@@ -71,7 +73,8 @@ Response:
 --------------------------------------------------
 {
     "aggregations": {
-        "ip_ranges": [
+        "ip_ranges": {
+            "buckets": [
                 {
                     "key": "10.0.0.0/25",
                     "from": 1.6777216E+8,
@@ -91,4 +94,5 @@ Response:
             ]
         }
     }
+}
 --------------------------------------------------

docs/reference/search/aggregations/bucket/range-aggregation.asciidoc

@@ -31,7 +31,8 @@ Response:
     ...
 
     "aggregations": {
-        "price_ranges": [
+        "price_ranges" : {
+            "buckets": [
                 {
                     "to": 50,
                     "doc_count": 2
@@ -48,6 +49,7 @@ Response:
             ]
         }
     }
+}
 --------------------------------------------------
 
 ==== Keyed Response
@@ -82,6 +84,7 @@ Response:
 
     "aggregations": {
         "price_ranges" : {
+            "buckets": {
                 "*-50.0": {
                     "to": 50,
                     "doc_count": 2
@@ -98,6 +101,7 @@ Response:
             }
         }
     }
+}
 --------------------------------------------------
 
 It is also possible to customize the key for each range:
@@ -200,7 +204,8 @@ Response:
 --------------------------------------------------
 {
     "aggregations": {
-        "price_ranges": [
+        "price_ranges" : {
+            "buckets": [
                 {
                     "to": 50,
                     "doc_count": 2,
@@ -238,6 +243,7 @@ Response:
             ]
         }
     }
+}
 --------------------------------------------------
 
 If a sub aggregation is also based on the same value source as the range aggregation (like the `stats` aggregation in the example above) it is possible to leave out the value source definition for it. The following will return the same response as above:

docs/reference/search/aggregations/bucket/terms-aggregation.asciidoc

@@ -274,8 +274,8 @@ There are two mechanisms by which terms aggregations can be executed: either by
 data per-bucket (`map`), or by using ordinals of the field values instead of the values themselves (`ordinals`). Although the
 latter execution mode can be expected to be slightly faster, it is only available for use when the underlying data source exposes
 those terms ordinals. Moreover, it may actually be slower if most field values are unique. Elasticsearch tries to have sensible
-defaults when it comes to the execution mode that should be used, but in case you know that an execution mode may perform better
+defaults when it comes to the execution mode that should be used, but in case you know that one execution mode may perform better
-than the other one, you have the ability to provide Elasticsearch with a hint:
+than the other one, you have the ability to "hint" it to Elasticsearch:
 
 [source,js]
 --------------------------------------------------

src/main/java/org/elasticsearch/search/aggregations/bucket/histogram/InternalHistogram.java

@@ -363,10 +363,11 @@ public class InternalHistogram<B extends InternalHistogram.Bucket> extends Inter
 
     @Override
     public XContentBuilder toXContent(XContentBuilder builder, Params params) throws IOException {
-        if (keyed) {
         builder.startObject(name);
+        if (keyed) {
+            builder.startObject(CommonFields.BUCKETS);
         } else {
-            builder.startArray(name);
+            builder.startArray(CommonFields.BUCKETS);
         }
 
         for (B bucket : buckets) {
@@ -396,7 +397,7 @@ public class InternalHistogram<B extends InternalHistogram.Bucket> extends Inter
         } else {
             builder.endArray();
         }
-        return builder;
+        return builder.endObject();
     }
 
 }

src/main/java/org/elasticsearch/search/aggregations/bucket/range/InternalRange.java

@@ -294,26 +294,27 @@ public class InternalRange<B extends InternalRange.Bucket> extends InternalAggre
             out.writeDouble(((Bucket) bucket).from);
             out.writeDouble(((Bucket) bucket).to);
             out.writeVLong(((Bucket) bucket).docCount);
-            ((Bucket) bucket).aggregations.writeTo(out);
+            bucket.aggregations.writeTo(out);
         }
     }
 
     @Override
     public XContentBuilder toXContent(XContentBuilder builder, Params params) throws IOException {
-        if (keyed) {
         builder.startObject(name);
+        if (keyed) {
+            builder.startObject(CommonFields.BUCKETS);
         } else {
-            builder.startArray(name);
+            builder.startArray(CommonFields.BUCKETS);
         }
         for (B range : ranges) {
-            ((Bucket) range).toXContent(builder, params, formatter, keyed);
+            range.toXContent(builder, params, formatter, keyed);
         }
         if (keyed) {
             builder.endObject();
         } else {
             builder.endArray();
         }
-        return builder;
+        return builder.endObject();
     }
 
 }