Java api: add missing support for boost to GeoShapeQueryBuilder and TermsQueryBuilder

[javanna]

Both parsers support boost and parse it properly but when we create the query through java api we couldn't set the boost.

Relates to #11744

[jpountz]

LGTM

This made me learn about BoostableQueryBuilder, could we open a follow-up issue to make this class pkg-private?

[javanna]

if we make BoostableQueryBuilder package private, custom queries cannot implement it unless they are in the same package? Not sure that's good for plugins.

[jpountz]

My understanding is that this interface is just a way to avoid re-defining the boost method (including javadocs) on every builder since core has tens of queries. Is it more than that? If no, then plugins could just make their queries implement setBoost without inheriting this interface, or even duplicate this interface?

[javanna]

yes they could do that, but why would they? What's the advantage of making the interface package private in core?

[jpountz]

In my opinion, it has several benefits:

• if you generate javadocs, the setBoost() method would appear as defined on each query builder as opposed to being inherited from this BoostableQueryBuilder class
• BoostableQueryBuilder would not be part of the API: imagine someone starts using "instanceof BoostableQueryBuilder" to know if a query supports boosting, then modifying/removing this interface would be considered a break, although it was only added for convenience in the beginning
• limited coupling between the core and plugins: we could change this BoostableQueryBuilder class in whatever way we want without having any impact on plugins

I think these benefit are worth having a few duplicated lines of code in plugins.

[javanna]

thanks for the explanation @jpountz , I opened #11815 for this. Also, btw we may be removing this interface at some point too in the query-refactoring branch, as part of the consolidation of queryname and boost, we will see. This change gives us the freedom to do it indeed.