Triggerable CI merge request verification

In our current development process CI scripts start verification of every merge request and any revision that appears on Gerrit. But most of these tests are useless because while they are running several new revisions can be posted and even more tests are scheduled. This is a massive waste of our CI processing power.

It would be better to make starting of CI verifications triggerable by a commiter generated event. Before this event revisions should not be scheduled for verifications. Systax check tests are very cheap and should work always for all revisions regardless of trigger event. Same as before a patch can be merged ONLY in it gets +1 from verification AND syntax check.

What can be a trigger event?

By a comment:

In the past we had syntax checker that could be retriggered by a specific comment "Restest this please". We could use this technique again and make verification to be initiated by a comment that consists only of the "verify" string.

We could go even farther and make it possible to choose which OS and mode we want to be verified. For example, 'verify centos simple'. Yes, I know that we are going to remove simple mode and you can run custom test in Jenkins jobs.

By the workflow:

There is also workflow feature we dont use much. You can set this values:
-1 - Work in progress
0 - Ready for review (default)
+1 - Approved (restricted for me somehow)
If it's possible to get this data from a revision why not make use of this?
Can we change what is the default state of a patch?
Can we remove restriction on +1.

If we can set -1 to be default, which is logical to have work-in-progress for default, we could trigger tests only when a commiter have set the value >= 0.
If we can remove restriction on setting +1 we could trigger test only when commiter sets the value to +1 (approved).

Or invent some other way for a commiter to trigger verification...

How the workflow could look like?

1. Commiter makes a new patch set. Sysnatx is checked olmost instantly and not verification is started.
2. Commiters shows this patch to other developers, there are discussions, +1s/-1s and several more patch sets are made.
3. Commiters sets the trigger event and only now verification of only the last patch set is started and (hopefully) commiter gets +1 from CI.
4. Now patch has several +1s from developers and +1 from CI and can be merged. Only one verification test was made and there could have been a lot of previous revisions.

Alternatively, a commiter can choose to set trigger event right after the patch to get +1 from CI first and from developers later.