[FLINK-11643] remove useless code of externalizedCheckpointsDir

[yuqi1129]

What is the purpose of the change

Remove unless code of externalizedCheckpointsDir, besides make tiny changes to StateBackendLoader.java to be more readable

Brief change log

• Remove unused code of externalizedCheckpointsDir and make some tiny changes in class StateBackendLoader

Verifying this change

This change is a trivial rework / code cleanup without any test coverage.

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

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

Documentation

• Does this pull request introduce a new feature? (no)

[flinkbot]

Thanks a lot for your contribution to the Apache Flink project. I'm the @flinkbot. I help the community
to review your pull request. We will use this comment to track the progress of the review.

Review Progress

• ❓ 1. The [description] looks good.
• ❓ 2. There is [consensus] that the contribution should go into to Flink.
• ❓ 3. Needs [attention] from.
• ❓ 4. The change fits into the overall [architecture].
• ❓ 5. Overall code [quality] is good.

Please see the Pull Request Review Guide for a full explanation of the review process.

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot approve description to approve the 1st aspect (similarly, it also supports the consensus, architecture and quality keywords)
• @flinkbot approve all to approve all aspects
• @flinkbot approve-until architecture to approve everything until architecture
• @flinkbot attention @username1 [@username2 ..] to require somebody's attention
• @flinkbot disapprove architecture to remove an approval

[klion26]

As you have changed this, should we add a test logic that is info log enabled?

[yuqi1129]

This is a minor change, i will add a test logic as you suggested, thanks

[StefanRRichter]

I would suggest to revert the introduction of logIsNotNull. What is the benefit of the change?

[yuqi1129]

I just think logIsNotNull is more readable as there are many logger != null logic in the method. Ok, i will revert this point if it make no sense.

[zentol]

No longer applicable.