Refactor "multi" handlers to use listen

[VannTen]

What type of PR is this?
/kind cleanup

What this PR does / why we need it:

We have some handlers which do nothing but notify other handlers (using command: /bin/true + notify)
This replaces all of them to use listen, which allow handlers to be triggered by one or more "listen topics"
(see https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_handlers.html#naming-handlers)

The benefits are mostly for developing or debugging, when looking which handlers are triggered by a particular notify:
instead of grepping twice, we only need to do it once.

I did some quick testing to see if their was any performance difference (from less /bin/true commands executed across ssh),
but it does not seems to make any noticeable differences, at least on a small cluster.

Special notes for your reviewer:
I made one commit per role to make it more digestable, but I can squash that if you prefer.

Regarding the pre-install role: I'm not sure the when are completely coherent here regarding the Flatcar stuff:
While the first "multi handler" was not run for Flatcar, most of the actual handlers were still triggered, since "Preinstall | reload kubelet" is run for Flatcar as well.
The change have made should not alter the execution flow, but maybe a follow-up PR (and someone more knowledgeable about Flatcar) should examine that.

Does this PR introduce a user-facing change?:

Refactor "multi" handlers to use listen

[k8s-ci-robot]

Hi @VannTen. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[yankay]

/ok-to-test

[VannTen]

Rebased to fix conflicts

[VannTen]

Looks like the CI runner had a a system failure
/retest

[floryut]

Looks like the CI runner had a a system failure /retest

Indeed, retrying

[VannTen]

/retest

[floryut]

@VannTen Nice and cleaner 👍

[MrFreezeex]

Thanks! looks much cleaner! :D
/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: floryut, MrFreezeex, VannTen

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [floryut]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Saigut]

Hello, does this change of code can ensure the handler be executed in an expected order?
For example in this file cri-dockerd/handlers/main.yml, will the handlers be executed in the order: Cri-dockerd | reload systemd -> Cri-dockerd | restart docker.service -> ... -> Cri-dockerd | enable cri-dockerd service?

[VannTen]

Handlers are executed in the order they are defined, regardless of the order in which they are notified: see https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_handlers.html#notifying-handlers