[roadmap] Add support for plugin-defined custom components

[swallez]

Description

The current implementation of query/aggregation/property/suggester and index settings does not allow for custom components.

It could have the following shapes (example for a custom aggregation):

The most direct way is to use raw JSON:

JsonData pluginAgg = ... // Create a JSON node tree

var result = esClient.search(s -> s
  .aggregation("foo", a -> a
    // The plugins expects the "my-plugin" type
    // The leading underscore indicates that it's a framework-level
    // feature and not a builtin "custom" variant (such a variant
    // exists for example in analyzers)
    ._custom("my-plugin", pluginAgg)
  )
);

var someResult = result
    .aggregations()
    .get("foo")
    // Check variant id received from ES and return it as JsonData
    ._custom("my-plugin")
    // Traverse the resulting JsonData tree
    .toJson().asJsonObject().getString("foo");

Additionally, if you want to enforce strong typing guarantees in requests and make it easier to traverse responses, you can define classes to map the plugin's JSON structures to. In the example below each class is a POJO that implements a specific extension point defined in the Java API client, and has a ExtensionId annotation indicating the variant name in the JSON payloads:

@ExtensionId("my-plugin")
class MyPluginAgg implements AggregationExtension {
  ...
}

@ExtensionId("my-plugin")
class MyPluginAggResult implements AggregateExtension {
  ...
}

MyPluginAgg pluginAgg = new MyPluginAgg(...);

var result = esClient.search(s -> s
  .aggregation("foo", pluginAgg)
);

var someResult = result
    .aggregations()
    .get("foo")
    // Deserialize and downcast to target class
    ._custom(MyPluginAggResult.class)
    .foo();

[swallez]

Also applies do highlighters #168