[FLINK-26782] Remove PlannerExpression and related

[dawidwys]

What is the purpose of the change

Uses the new type inference stack for infering types for the legacy UDF stack.

A no-goal of the PR is to make the logic in LegacyUserDefinedFunctionInference more maintainable. It is also a no-goal to move the entire logic 1-1. The legacy is stack is obsolete and this is only a best effort on still supporting it in Table API.

Verifying this change

Existing tests pass. I have not added tests for the LegacyUserDefinedFunctionInference because

1. it is just a port of UserDefinedFunctionUtils
2. old UDF stack is obsolete and this is only a best effort approach on still supporting them in Table API

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): (yes / no)
• The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
• The serializers: (yes / no / don't know)
• The runtime per-record code paths (performance sensitive): (yes / no / don't know)
• Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (yes / no / don't know)
• The S3 file system connector: (yes / no / don't know)

Documentation

• Does this pull request introduce a new feature? (yes / no)
• If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

[flinkbot]

CI report:

• 4f2c788 Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run azure re-run the last Azure build

[jnh5y]

(nit) No need to create a stream to iterate and then make an array.

Looks like https://docs.oracle.com/javase/8/docs/api/java/util/Arrays.html#setAll-T:A-java.util.function.IntFunction- may be an option for doing this in one step / re-using the lambda.

(I don't necessarily think this needs to be addressed.)

[dawidwys]

Not sure if that's a better approach.

To be honest I like the single chain approach a bit more. What you're suggesting would look:

final Class<?>[] array = new Class<?>[expectedLength];
        Arrays.setAll(array, i -> {
            if (i < matchingSignature.length - 1) {
                return matchingSignature[i];
            } else if (isVarArgs) {
                return matchingSignature[matchingSignature.length - 1]
                        .getComponentType();
            } else {
                // last argument is not an array type
                return matchingSignature[matchingSignature.length - 1];
            }
        });
        return array;

[jnh5y]

Here it won't matter (much).

In the old days, Scala could generate tons of intermediate objects to handle things like this. That got me used to looking for when objects were being created just to perform iteration.

This code just reminded me of situations like that!

[jnh5y]

See the comment about skipping on making a stream and using Arrays.setAll.

[jnh5y]

(nit) Reorder:

                || candidate == TimestampData.class && expected == LocalDateTime.class
                || candidate == LocalDateTime.class && expected == TimestampData.class
                || candidate == Timestamp.class && expected == TimestampData.class
                || candidate == TimestampData.class && expected == Timestamp.class

[dawidwys]

I'd rather keep the original order from UserDefinedFunctionUtils

[jnh5y]

Could this check be moved to checkAndExtractMethods?

[jnh5y]

Seems like no volatile method are ever returned?

[dawidwys]

Could this check be moved to checkAndExtractMethods?

I'd rather keep the logic as similar to UserDefinedFunctionUtils as possible. Especially in such a subtle areas as this one. I don't want to analyze all possible corner cases in a class that should be removed any time soon.

[jnh5y]

Looks good to me.