Avoid duplicate requests in index nested loops joins

Nobody has claimed this yet.

Both alternatives of the index nested loops join (ExecOpGenericIndexNestedLoopsJoinWithRequestOps and ExecOpGenericIndexNestedLoopsJoinWithRequests) are considering all input solution mappings separate from one another. As a consequence, the same request may be created and processed multiple times.

For instance, assume two solution mappings with the same value for variable ?x and different values for variable ?y, and ?x is the join variable (i.e., the triple pattern considered by the iNLJ contains ?x). Then, for each of the two solution mappings, the same triple pattern request is created (by replacing the variable ?x in the triple pattern with the same value).

While the second of these requests (and note that there may be many more than just two!) may ultimately be served from the request cache, creating and processing it should be avoided. The purpose of this issue is to develop and implement an approach to do so.

Start by reading ExecOpGenericIndexNestedLoopsJoinWithRequestOps and ExecOpGenericIndexNestedLoopsJoinWithRequests, then trace how each creates requests and how the request cache is used. Reproduce the two-solution-mapping scenario described in the issue and determine where equivalent instantiated triple-pattern requests can be identified. Done means each unique request is created and processed only once.

Written by the indexing model from the issue text.