[FLINK-31782][runtime] Makes DefaultLeaderElectionService implement MultipleComponentLeaderElectionDriver.Listener

[XComp]

• [FLINK-30765][runtime] Aligns the LeaderElectionService.stop() contract #21742
• [FLINK-31768][runtime] Removes contender description #22379
• [FLINK-31838][runtime] Moves thread handling for leader event listener calls from DefaultMultipleComponentLeaderElectionService into DefaultLeaderElectionService #22422
• [FLINK-31773][runtime] Separate DefaultLeaderElectionService.start(LeaderContender) into two separate methods for starting the driver and registering a contender #22380
• [FLINK-31786][runtime] Removes unused classes #22623
• [FLINK-31776][runtime] Introduces LeaderElection interface #22384
• [FLINK-31785][runtime] Moves LeaderElectionService.stop into LeaderElection.close #22390
• [FLINK-31797][runtime] Moves LeaderElection creation into HighAvailabilityServices #22404
• [FLINK-31781][runtime] Introduces the contender ID to the LeaderElectionService interface #22601
• [FLINK-32177][runtime] Refactors MultipleComponentLeaderElectionDriver.Listener.notifyAllKnownLeaderInformation signature #22642
• === THIS PR === FLINK-31782
• [FLINK-32180][runtime] Moves error handling from DefaultMultipleComponentLeaderElectionService into the MultipleComponentLeaderElectionDriver implementations #22656
• [FLINK-31783][runtime] Migrates DefaultLeaderElectionService from LeaderElectionDriver to the MultipleComponentLeaderElectionDriver interface #22661

What is the purpose of the change

Makes DefaultLeaderElectionService implement MultipleComponentLeaderElectionDriver.Listener besides the LeaderElectionEventHandler interface.

Brief change log

• Makes DefaultLeaderElectionService implement MultipleComponentLeaderElectionDriver.Listener
• Modifies MultipleComponentLeaderElectionDriver.Listener in a way that isLeader requires the session ID to be passed in instead of generating it internally. This aligns more with how LeaderElectionEventHandler was implemented. It also makes more sense because the HA backend should be the owner of the session ID: Theoretically, it could provide such a session ID.

Verifying this change

• The test code is adapted in a way that it only uses the MultipleComponentLeaderElectionDriver.Listener methods.

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, Kubernetes/Yarn/Mesos, ZooKeeper: yes
• The S3 file system connector: no

Documentation

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

[flinkbot]

CI report:

• 5c4135c Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

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

[zentol]

I don't really follow the UUID change. If the multiCLES got by without it so far, what do we need it for now?

the HA backend should be the owner of the session ID: Theoretically, it could provide such a session ID.

Sure, is either ZK/k8s doing that though? Would we gain anything by it?

[XComp]

I don't really follow the UUID change. If the multiCLES got by without it so far, what do we need it for now?

the HA backend should be the owner of the session ID: Theoretically, it could provide such a session ID.

Sure, is either ZK/k8s doing that though? Would we gain anything by it?

The initial motivation was to align it with LeaderElectionEventHandler#onGrantLeadership to reduce the effort in migrating the legacy tests to the new interface (it feels like there are more tests for the legacy code; but I didn't count). I found it handy in tests where the test code can define the sessionID as the expected one and we can rely on it without needing to extract it from somewhere. Also from a semantical point of view it made sense (as it is stated in the comment you quoted).

But I can hide the sessionID again to reduce the diff. I might have overestimated the consequences of keeping it the way the LeaderElectionEventHander is doing it

[XComp]

New rebase onto FLINK-32177 that fixes the conflicts with master

[XComp]

Rebase after adding the checkstyle fix to FLINK-32177 and rebasing it to master

[XComp]

Rebased to master after FLINK-32177 was merged.