analyzer: add rule to prune unnecessary columns

[erizocosmico]

Closes #570

Also fixes a bug we didn't notice that didn't resolve correctly in reorder projection.

[ajnavarro]

why do we need subqueryBarrier on top of subqueries? why not just apply the rule on the subqueries til the tree that is going out the Analyzer is the same as the tree going in?

[erizocosmico]

Since TransformUp goes first from the innermost node to the topmost node all nodes inside the subquery will have been transformed before getting to the SubqueryAlias. Without that node you cannot prune columns inside a subquery, because in the outer query the columns coming from the subquery have the subquery as table, but not inside.

So, if we have:

SELECT t.foo FROM (SELECT t1.foo, t1.bar FROM t1) t

We gather the used columns, which are t.foo. The first node transformed is t1, followed by the project inside the subquery, which will not find t1.foo or t1.bar in the used columns, removing them both.

The subquery barrier is there to prevent this from happening and analysing the subquery correctly as an independent unit having the correct table references in the used columns.

[ajnavarro]

Oh, I see, thanks for the explanation.

Could this be avoided implementing transform downs too?

[erizocosmico]

Not only transform downs. It would require a TransformDown and a way to stop transforms, so that when you get to a SubqueryAlias, you can stop the transformation and transform that node and their childrens on your own. That is so because a subquery needs to be transformed with a different set of used columns than the parent.