Refactor derived source for nested field types

[jmazanec15]

Description

Refactors derived source nested injector to be more readable and reliable. Moves low-level lucene calls into a helper class. Simplifies the iterator and the injector.

The overall logic for the nested portion is complex because of the following case:

Assume we have the following document from the user and we are deriving the value for nested.vector
{
  "nested": [
    {
      "text": "text1"
    },
    {
      "vector": [vec1]
    },
    {
      "vector": [vec2],
      "text": "text2"
    }
  ]
}

This would get filtered and serialized as:
{
  "nested": [
    {
      "text": "text1"
    },
    {
      "text": "text2"
    }
  ]
}

We need to ensure that when we want to inject vec1 back, we create a new map and put it in between
the existing fields.

To do this, we need to know what docs the existing 2 maps map to.

My strategy to map the items in the source to docIds is to:

1. Match a fieldInfo that the document must have
2. After the given offset, find the first document that has this field
3. Get the next doc that is a sibling of the field being injected.

Because of the complexity, for 3.0, this PR also blocks enabling this feature for fields with more than 2 levels of nesting. This includes object fields as well. The focus will be getting this to work in a very stable fashion before moving on to generalized support.

Additionally, it adds a new integ test. I want to add a lot more unit tests, but wanted to put out a PR to get initial feedback.

Related Issues

Resolves #[Issue number to be closed when this PR is merged]

Check List

• Commits are signed per the DCO using --signoff.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[msfroh]

Are we going to want to use this multiple times in a single request? Would it make sense to return the DocIdSetIterator instead?

[jmazanec15]

We will make this call multiple times, but for the field will not be consistent. But we could reuse if we map it to a particular field.