Completion Suggester: Add doc-values based payload support

[areek]

Note: the PR is against feature/completion_suggester_v2 branch

Followup of #13576 (comment). The PR enables returning any doc values enabled fields as suggestion payload.

One can specify fields to be returned as part of the suggestion payload at query time, using the
payload option:

POST music/_suggest 
{
  "song-suggest" : {
    "prefix" : "nev",
    "completion" : {
      "field" : "song_suggest"
      "payload" : [ "title" ]
    }
  }
}

The specified payload field values will be returned as part of the suggestion payload:

{
  "song-suggest": [
    {
      "text": "nev",
      "offset": 0,
      "length": 4,
      "options" : [ {
        "text" : "Nirvana",
        "score" : 34.0,
        "payload" : {
          "title" : [ "Nevermind" ]
        }
      } ]
    }
  ]
}

Now suggestion payload are not part of the completion (FST) index, as was the case before. Payload fields are fetched for the top N completions per shard hence specifying payload fields will incur additional search performance hit.

[mikemccand]

Maybe a bit better error checking here? E.g. if you see a START_OBJECT token, that's not allowed right?

[areek]

Thanks for the pointer, I have made it stricter and also added tests to ensure it errors out on malformed input

[mikemccand]

This looks great, thanks @areek, I left a few small comments.

Net/net this is more functionality vs. current suggesters, since you can retrieve more than one field as the payload (vs only one payload per suggestion today), and they can be typed fields (numbers, dates, etc.) too.

The code is also quite simpler than supporting the 2nd fetch phase ...

[rmuir]

Wait we are using docvalues as stored fields now? I do not think this is something we should do.

[s1monw]

Wait we are using docvalues as stored fields now? I do not think this is something we should do.

I think for the suggest usecase that's a good alternative to putting it into the FST. We will deprecate this option as well once we have the second roundtrip query_then_fetch for this too but that will go into 3.x

[areek]

Thanks @mikemccand for the review, addressed all your feedback. I think the docs can be improved to encourage users to use doc values enabled fields for payload? Maybe @clintongormley has some thoughts?

@rmuir this is added to make the new implementation have feature parity with the current suggester and as @s1monw mentioned will go away in 3.x, where documents will be fetched in the 2nd phase.

[clintongormley]

@areek I like it

[mikemccand]

Thanks @areek, LGTM.