Refactor the subquery code and fix outer condition queries

[jsternberg]

This change refactors the subquery code into a separate builder class to
help allow for more reuse and make the functions smaller and easier to
read.

The previous function that handled most of the code was too big and
impossible to reason through.

This also goes and replaces the complicated logic of aggregates that had
a subquery source with the simpler IteratorMapper. I think the overhead
from the IteratorMapper will be more, but I also believe that the actual
code is simpler and more robust to produce more accurate answers. It
might be a future project to optimize that section of code, but I don't
have any actual numbers for the efficiency of one method and I believe
accuracy and code clarity may be more important at the moment since I am
otherwise incapable of reading my own code.

Fixes #8045.

• Rebased/mergable
• Tests pass
• CHANGELOG.md updated

[jsternberg]

@rkuchan is it possible for you to test this out with a few scenarios? I added some tests, but some human eyes would also be good.

@jwilder I'm not 100% confident in the performance characteristics of this, but I give my rationale for why I think it's a positive change anyway in the PR. What do you think?

[jsternberg]

This isn't a high priority for testing. We're going to push it to the 1.3 release since it's more involved than other bugfixes.

[jsternberg]

I still need to expand the benchmarks to cover more aspects, but the initial numbers are not promising for the simplest case:

benchmark                                     old ns/op     new ns/op     delta
BenchmarkSelect_Subquery_Aggregate_1K-8       785914        832085        +5.87%
BenchmarkSelect_Subquery_Aggregate_100K-8     62048569      72915654      +17.51%

benchmark                                     old allocs     new allocs     delta
BenchmarkSelect_Subquery_Aggregate_1K-8       7070           7077           +0.10%
BenchmarkSelect_Subquery_Aggregate_100K-8     700076         700083         +0.00%

benchmark                                     old bytes     new bytes     delta
BenchmarkSelect_Subquery_Aggregate_1K-8       411989        412261        +0.07%
BenchmarkSelect_Subquery_Aggregate_100K-8     40804498      40804770      +0.00%

That may not be an acceptable speed loss. Especially with 100K points.

[jsternberg]

I am so confused, but rerunning the benchmarks that I have locally on my computer gives me this now:

jsternberg:[~/g/s/g/i/influxdb] $ (tmp $) benchcmp old.txt new.txt
benchmark                                     old ns/op     new ns/op     delta
BenchmarkSelect_Subquery_Aggregate_1K-8       794322        783705        -1.34%
BenchmarkSelect_Subquery_Aggregate_100K-8     63811348      61522037      -3.59%

benchmark                                     old allocs     new allocs     delta
BenchmarkSelect_Subquery_Aggregate_1K-8       7070           7077           +0.10%
BenchmarkSelect_Subquery_Aggregate_100K-8     700076         700083         +0.00%

benchmark                                     old bytes     new bytes     delta
BenchmarkSelect_Subquery_Aggregate_1K-8       411989        412261        +0.07%
BenchmarkSelect_Subquery_Aggregate_100K-8     40804498      40804770      +0.00%

If true, this is definitely acceptable. I'm also trying to use the same old technique for subqueries that I was using, but trying to get the changes I made in this query and I am finding it very difficult to keep track of the code.