Align metadata propagation through Physical and Logical casts

[paleolimbot]

Which issue does this PR close?

• Closes Propagation of metadata through casts can strips extension type from the destination field and can result in invalid extension types #22079

Rationale for this change

The logical Expr::Cast and Expr::TryCast have a FieldRef target that was added in #18136 so that logical casts can express a cast to an extension type. In combination with a SQL type planner ( #20676 ) and an optimizer rule, this enabled casting to/from extension types with custom semantics to actually occur. The ability to do this was reverted by #20836 (which removed the original test) and I am not sure that ability ever made it into a release. When investigating this issue, it became clear the logical and physical cast behaviour had diverged with respect to the target field.

What changes are included in this PR?

This PR strips specific metadata keys (extension name and extension metadata) when propagating metadata from the source of a cast to the target (because doing so may result in an invalid destination field that consumers could reject), and propagates all metadata from the (logical) cast target field (e.g., so that a cast to an extension type represented by the cast target field will have a to_field() that communicates the extension type).

For the physical cast, this behaviour is replicated exactly (I hope).

Note that actually casting to an extension type can be implemented with an optimizer rule, planner, or by the mechanism I have in the works in #21071 .

Are these changes tested?

Yes

Are there any user-facing changes?

It was in practice not common to create a Expr::Cast with field metadata internally and thus I don't think users will see metadata changes from the inclusion of metadata from the target field. I would be surprised if stripping the extension name/metadata from the source was disruptive (it was more likely to have caused errors).

Superceeds an earlier but similar attempt ( #22162 ).

[paleolimbot]

This is a little gross feeling to me, but there's at least one place in the code that is counting on Cast::return_field() not to execute its child's return_field(): the virtual row number rewrite requires that the cast strips metadata and does not validate its child's Column (which is invalid, at least where it's tested). There may be a better way here.

[paleolimbot]

@adriangb @tschwarzinger @cyberbeam524 You've all kindly waited for me to finish this...happy to iterate on any of your comments here!