Gordon.hamilton/nested struct support

[gord02]

This PR is to change the substrait-java virtualTableScan to use nested structs in place of the now deprecated struct literals.

The issue

Key changes:

• Add the visitation pattern logic
• Proto to Rel conversion
• Rel to proto conversion
• Spark to Substrait
• Substrait to Spark
• SubstraitRelNodeConverter: substrait virtualTableScan to calcite logicalValues, required creating a project for non-literal expressions
• SubstraitRelVisitor: Calcite to substrait conversion that removes the extra project added to account for non-literal expressions

Testing:

• LogicalValuesTest tested the conversion from pojo to calcite node back to pojo

Testing:
./gradlew test --tests io.substrait.isthmus.LogicalValuesTest --debug-jvm

[bestbeforetoday]

@gord02 you will need to make sure that the subject line and text of all commits in your pull request conform to the structure dictated by conventional commits. You can look at the output of the Lint commits for semantic-release build check to see problems flagged, and also the CONTRIBUTING guide for tips.

When you have lots of commits that need fixing, it can sometimes be easier to squash them into fewer commits to reduce the number of changes you need to make.

[nielspardon]

Does this PR replace #417 which seems to have tried to do a similar change?

[gord02]

Hi @nielspardon! This PR completes and builds off of that PR yes. So it can be deleted.

[benbellick]

I created an issue to track this particular problem @ #587. @gord02 would you mind including it somewhere in your PR description so that it gets linked?

[benbellick]

I have left a few comments on here so far. I think some of them might cause some reshuffling around so I'll save some of the more in-depth suggestions for the future. One other thing, it would be great if you could introduce some test which specifically demonstrates the logic you introduced where deserialized protos can handle either the presence of fields or values, but not both. I can imagine a test in which you constuct two protos, one via values and one via fields, and just demonstrate that once you render them both as POJOs, they are equal. That's just one idea though.

Anyways, thanks for all of your work! Let me know if anything I wrote isn't clear :)

[benbellick]

This test has become a test for virtual tables instead of the intended Ddl test. You can see that the virtual table was just fed in as an input the ExtensionDdl builder as a viewDefinition. Were these changes actually necessary?

[benbellick]

instead of handling below the converion of proto -> expression for StructLiterals and StrutNested's inline, could we introduce method to handle conversions of Nested in ProtoExpressionConverter.java (once you do the above of having a Nested interface)? Similar to how it is handled for Literals.