Workaround behavior change in list parsing

[etseidl]

Which issue does this PR close?

• Closes Regression: Parsing List(Int64) results in nullable list in 57.0.0 and a non-nullable list in 57.1.0 #8883.

Rationale for this change

See issue...a prior PR changed the behavior of parsing lists. This PR temporarily reverts to the old behavior, but retains the ability to parse List(nullable Int64).

What changes are included in this PR?

Always sets nullable to true regardless of the presence or absence of the nullable token.

Are these changes tested?

Yes

Are there any user-facing changes?

No, this reverts to previous behavior.

[alamb]

Thanks @etseidl

The other thing I was thinking about was potentially changing the display so to List(Int64) means nullable (the default) and List(nonnull Int64) or something means non nullable (a more strict requirement).

Since we haven't released List(nullable ..) syntax yet I think we can change it

[etseidl]

That makes more sense to me if unannotated used to mean nullable. Coming from sql world, adding not null constraints feels more natural 🦕😅

[etseidl]

I'll leave this PR as is, and open a new one with changes to display.

#8890

[alamb]

That makes more sense to me if unannotated used to mean nullable. Coming from sql world, adding not null constraints feels more natural 🦕😅

You and me both 🙏