Add source_semantic_models property to DataflowPlanNode

[tlento]

This commit adds the source_semantic_models property to the DataflowPlanNode,
with a base case implementation of returning the recursively-collected set
of all source semantic models fed into the node parents, and the single
necessary override in ReadSqlSourceNode to populate the semantic model
reference as appropriate.

We currently have two use-cases for this, one in the cloud product
that needs the semantic model inputs for a dataflow plan, and the
upcoming predicate pushdown evaluation which needs the semantic model
inputs for a given DataflowPlanNode.

This is presented as a stand-alone change for discussion, as it
represents a departure from our previous de facto approach of limiting
all traversal operations to visitor classes. There are, in fact,
three alternatives to adding this property which would all suffice
for the purposes of predicate pushdown:

1. Write a separate class to do the traversal and fetch the property
   only from the ReadSqlSourceNodes.
2. Use an existing property accessor to collect this information,
   either via restricting return types from the SourceNodeSet or by
   using the existing resolver and consolidating the column-level
   semantic model references
3. Add this property as seen here.

The second option will not address the case on the cloud side, so
I chose between the traversal and the approach seen here. I went
with this for the following reasons:

1. This is, conceptually, a property of the DataflowPlanNode. Up until
   now the existence of this property has been implicit - at some point,
   at the root of all executable DataflowPlan DAGs, is at least one ReadSqlSourceNode
   sourced from a semantic model. Adding an explicit accessor makes it more
   obvious that this is our baseline expectation. The fact that it can be
   an empty set is a shortcoming, but not a terrible one.
2. This limits the scope of what we need to import across module (or
   even repository) boundaries in order to access this property information.
   With a separate visitor, we'd have to always import a separate class
   that implements the DataflowPlanNodeVisitor interface and pulls in
   those other elements.
3. The property return type is always obvious to the caller, who likely
   does not care how we got the information.

The disadvantages here are:

1. This is the first break in our current "traversals are always visitors"
   model, which is a bit annoying as now we need to look in two places to
   find traversal operations. However, this is already true on the other side

• we have a number of implicit property accessors which we fetch via visitors -
  and I believe we'll end up in a better place if we move those to be properties
  instead.

2. There may be other recursive property access operations we need to make,
   and these may be scattered around across multiple node objects. There are
   ways to consolidate this - including allowing a visitor-style class to operate
   on these nodes and encapsulating it within the property accesor itself - but
   that is not necessary at this juncture.

[tlento]

• Add source_semantic_models property to DataflowPlanNode #1217 👈
• Use pushdown params to disable time range constraint pushdown #1216 : 1 other dependent PR (#1218 )
• Encapsulate time range constraints for predicate pushdown #1215
• Add conversion metric rendering tests #1214
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @tlento and the rest of your teammates on Graphite

[github-actions]

Thank you for your pull request! We could not find a changelog entry for this change. For details on how to document a change, see the contributing guide.

[tlento]

Update - @plypaul and I have discussed this a bit and found a better approach.