[FLINK-39130][metrics] Allow native types in MetricConfig

[Izeren]

What is the purpose of the change

This allows using native types for the MetricConfig. Example usage is for FLIP-553 to allow configuring metric export batch size as: 1500 rather than "1500"

Brief change log

• Add support for MetricConfig to recognize Number values.

Verifying this change

• Unit tests for MetricConfig.java

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:

• ba37c11 Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

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

[davidradl]

I am wondering whether we could have a parameterized test for this. As the tests are basically the same for each native type.

[Izeren]

For defaults and strings, makes sense, will do. For "cross" not sure it is going to be more readable

[davidradl]

that split makes sense

[Izeren]

Actually, I have tried it out, and for cross it is still more readable, so I made all categories parametrized

[1996fanrui]

Thanks for the fix, IIUC, this is a bug for all 2.x series, right?

If so, would you mind backporting it to all 2.x branch? thanks in advance.

[Izeren]

@1996fanrui, I am not sure whether it is a "bug". Because MetricConfig was never supporting numbers provided not as strings. If you believe it is beneficial, I can backport it once it is merged

[Izeren]

@1996fanrui, actually, I now think you are right and it was a regression in 2.0 since YAML parser was introduced which was able to process native types and not store them as strings. I will convert this subtask into bug and will backport this in previous 2 versions as well once we get this one merged

[1996fanrui]

@1996fanrui, actually, I now think you are right and it was a regression in 2.0 since YAML parser was introduced which was able to process native types and not store them as strings. I will convert this subtask into bug and will backport this in previous 2 versions as well once we get this one merged

Thanks for looking into! Let's leave this open for a while to see if there are any other comments before merging.

[Izeren]

@1996fanrui, I have created backport PRs for the last 2 releases:
#27670
#27671