Tezt: Add migrations scenario test for accuser

What

Closes #7957 (closed).

Adding a migration scenario in the double_consensus.ml tezt test for accusers.

Why

We need to cover the behaviour of the accuser for the protocol migration case, especially considering that we have the agnostic accuser and we plan to use it in the future.

How

By adding a new test which starts two accusers and checks that they behave correctly through a protocol migration.

Manually testing the MR

Check that dune exec tezt/tests/main.exe -- --file double_consensus.ml --verbose passes.

NOTE: One can observe that running (without the last commit of the MR, which fixes the problem below)

dune exec tezt/tests/main.exe -- --file double_consensus.ml --verbose --title 'accuser works correctly under migration from r022 to s023'

the accuser from the r022 protocol keeps verifying the operations even after the protocol migration occurs. For migration from s023 to alpha, this does not have any issue, but from r022 to s023, we get something like:

[10:14:14.785] [accuser1] Jun 09 11:14:14.785: 022-PsRiotum: error while baking:
[10:14:14.785] [accuser1] Jun 09 11:14:14.785:   Rpc request failed:
[10:14:14.785] [accuser1] Jun 09 11:14:14.785:      - meth: GET
[10:14:14.785] [accuser1] Jun 09 11:14:14.785:      - uri: http://127.0.0.1:52810/chains/main/blocks/head/helpers/validators?level=9
[10:14:14.785] [accuser1] Jun 09 11:14:14.785:      - error: Failed to parse the answer (application/octet-stream):
[10:14:14.785] [accuser1] Jun 09 11:14:14.785:                 error:
[10:14:14.785] [accuser1] Jun 09 11:14:14.785:                   Failed to parse binary data: Unexpected tag 9.
[10:14:14.785] [accuser1] Jun 09 11:14:14.785:                 content:
[10:14:14.785] [accuser1] Jun 09 11:14:14.785:                   "\000\000\003\003\000\000\002\255\000\000\000\t\000\231g\0152\003\129\007\165\154+\1
...

The issue comes from the change of the encoding from !17703 (merged).

The cause is that ther022 accuser continues monitoring operations from the next protocol, as can be seen in the worker_loop from client_baking_denunciation.

Solution:

In the accuser, we only take into consideration blocks that have next_protocol = <accuser protocol>, therefore the migration block is not verified. When the protocol changes, no new blocks are assigned to the "old accuser" because they do not get obtained from the blocks stream, but the story is different with the operations stream. Therefore, in this MR, I move the next_protocol <> Protocol.hash in the accuser and when this happens, we stop the accuser worker_loop, so that no operations get verified from the new protocol.

(Thanks a lot @ACoquereau for the suggestion and the explanations!)

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR