Query refactoring: query_string query

[javanna]

Refactoring of the query_string query: adds serialization bits, validate, equals, hashcode and tests for QueryStringQueryBuilder. Lucene query generation moved to toQuery method. Used QueryParserSettings as intermediate object, created on the data node, to provide arguments to MapperQueryParser for the lucene query parsing.

Relates to #10217

[javanna]

This PR contains a little breakage for the java api, as the QueryStringQueryBuilder#field(String) method doesn't allow to specify the boost in form field("field^2"). If you want to specify a boost you need to switch to QueryStringQueryBuilder#field(String, float) and do field("field", 2);

It also moves to parsing the locale using Locale#forLanguageTag which may cause backwards compatibility issue (see #13229).

[colings86]

Should these boolean option be boolean rather than Boolean and define a default? or does null mean something for these values?

[javanna]

only few stayed Boolean, I moved everything I could to primitive type. Exceptions are analyzeWildcard and allowLeadingWildcard. null there has a meaning (see toQuery method), as the value needs to be taken from the context, which we have only in toQuery, so we can't use it as a default value instead...

[colings86]

@javanna I left a few comments

[s1monw]

use isEmpty()?

[s1monw]

I added some comments

[javanna]

I have addressed some comments, replied to others, also added a TODO on unifying settings and query options for later on. It should be ready.

[s1monw]

LGTM

[javanna]

Merged 484fcd4

[alexksikes]

Not sure I'm a big fan of this. We should at least discuss it further?

[javanna]

This is a java api change only, you can always specify fields as "field1^5 field2^3" on the rest layer, but when using the java api you now have to do .field("field1", 5).field("field2", 3) instead of being able to do .field("field1^5").field("field2", 3) which makes no sense from a java point of view. There is a better method that accepts two arguments, which is the way to go. I don't think we need to keep the old method that requires us to parse a string to get out the actual field name and the boost value as part of the java api builder, that's something that should happen only as part of query parsing. I think this clarifies the change and addresses your concerns.