feat: update substrait to 0.57.1

[wackywendell]

The validator seemed to be a bit out of date with the main substrait repo, so I decided to see what it would take to update it to current substrait. And... it wasn't too bad.

For new features, I simply added them to the validator as NotYetImplemented, so they should emit warnings (not errors).

The only place I added actual support was for IntervalDayToSeconds, which should now accept the precision/subseconds variety, and not just the deprecated microseconds.

[EpsilonPrime]

Thanks for working on getting this moving into the right direction. This is a great first step towards bringing the validator up to where it should be.

I suspect we will want to avoid releases until we address all of the basic requirements of the latest version (such as enforcing that function names have their accepted argument types in their names) but that shouldn't hold up this first, great step.

[EpsilonPrime]

Should we reject use of Interval as deprecated at this point or just return an error as we would likely do once the old fields are removed?

[wackywendell]

I'm still new to this code base, but I think this is an internal class that is not exported; it does not have a 1:1 match with the public protobuf files. So there isn't a way to do Interval (and not IntervalYearToMonth and IntervalDayToSecond) in protobufs right now - there's nothing to deprecate or return an error on.

Does that make sense? (Or am I missing something?)

[mbrobbel]

Thanks for working on this!

[wackywendell]

Thanks for the comments! I'm working through them now 👍

[wackywendell]

OK - I've addressed all the comments from code review. There's a couple above that I'm not sure I fully handled - let me know what you think!

And thank you both for your quick reviews, @EpsilonPrime and @mbrobbel !

[wackywendell]

Thanks for the reviews! The last thing seems to be the commit lints. I can do some squashing and rebasing to address, although I'm generally hesitant to change history on publicly available commits; it will make the review comments above hard to track. Is that worth doing here?

[mbrobbel]

Thanks for the reviews! The last thing seems to be the commit lints. I can do some squashing and rebasing to address, although I'm generally hesitant to change history on publicly available commits; it will make the review comments above hard to track. Is that worth doing here?

No, it doesn't matter. This repo uses squash merge, so it'll use the PR title as merge commit message.