Closes https://github.com/paritytech/opstooling/issues/174

Added a new step in the action that triggers review bot to stop approval
from new pushes.

This step works in the following way:
- If the **author of the PR**, who **is not** a member of the org,
pushed a new commit then:
- Review-Trigger requests new reviews from the reviewers and fails.

It *does not dismiss reviews*. It simply request them again, but they
will still be available.

This way, if the author changed something in the code, they will still
need to have this latest change approved to stop them from uploading
malicious code.

Find the requested issue linked to this PR (it is from a private repo so
I can't link it here)

<del>PR custom review is deprecated. Now `review-bot` performs these
functions.</del>
PR removes unused ci jobs and adjusts zombienet jobs for merge queues

cc @Bullrich

PR prepares CI to the GitHub Merge Queues. All github actions that were
running in PR adjusted so they can run in the merge queues. Zombienet
jobs will do nothing during PRs but they will run during merge queues.

Jobs that will be skipped during PR:
 - all zombienet jobs
 - all publish docker jobs

Jobs that will be skipped during merge queue:
 - check-labels
 - check-prdoc
 - pr-custom-review
 - review trigger

cc https://github.com/paritytech/ci_cd/issues/862

Moved the review event of review-bot to only be triggered in approvals.

Because we only update the required reviews when someone approves, this
will stop the bot from immediately requesting a new review when someone
comments or request changes as they should have been already notified in
the first batch.

Added if condition on review-bot's trigger so it does not trigger in
`draft` PRs.

Upgraded to version 2.1.0 which has paritytech/review-bot#94, a change
in the logic of the action to overcome some problems with permissions
coming from PRs from forks

For this, we needed to divide the actions into two files:
- A first action that triggers on PRs and reviews and uploads the PR
number.
- A second action which is triggered under the completion of the first
one and runs as the action normally runs (but won't have any problems
regarding permissions because it is triggered from the master branch)