[FLINK-33677][core] Remove flink-conf.yaml from flink dist.

[JunRuiLee]

What is the purpose of the change

This pr introduces breaking changes that will be included in FLINK-2.0: Remove flink-conf.yaml from flink dist.

Brief change log

Remove flink-conf.yaml from flink dist.

Verifying this change

This change is already covered by existing tests.

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:

• 4d135ef8a3b94751c433b64c01d1735b02e1ca60 Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

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

[JunRuiLee]

@zhuzhurk, thanks for the review, I've updated this pr accordingly, PTAL.

[JunRuiLee]

I've updated the PR to completely remove the standard YAML flag from the code. Additionally, I've removed the setStandardYaml calls from RocksDBStateBackendConfigTest#testConfigureForStCompressionPerLevel and ForStStateBackendConfigTest#testConfigureForStCompressionPerLevel, as discussed with @Zakelly. Although this case is inconsistent with previous behavior, it remains meaningful.

[Zakelly]

I've updated the PR to completely remove the standard YAML flag from the code. Additionally, I've removed the setStandardYaml calls from RocksDBStateBackendConfigTest#testConfigureForStCompressionPerLevel and ForStStateBackendConfigTest#testConfigureForStCompressionPerLevel, as discussed with @Zakelly. Although this case is inconsistent with previous behavior, it remains meaningful.

+1 for this part.

[JunRuiLee]

Thanks @zhuzhurk , I've updated this pr accordingly, PTAL.