Agnostic_baker: Introduce delay in killing old baker at migration

What

Closes #7818 (closed).

Why

Before this MR, when a new protocol was encountered (by observing the head of the chain, particularly the next_protocol field of the blocks' metadata), the existing baker process was being shutdown immediately, and the next protocol baker process was taking over. This is problematic if the migration block has a high round, because our agnostic baker would no longer be able to bake new blocks on the old protocol (on which we would still be). Therefore, it is safer to prolong the life of the old baker process for a few more levels, and when we are passed the migration point, we can safely kill the process.

This is explained in the related issue as well.

How

By moving the current_baker to an old_baker field in the agnostic baker state, which has a level_to_kill field, which dictates when we will terminate the old baker process.

Manually testing the MR

Testing this precise scenario is quite complicated because it would require simulating a network with high round blocks at migration level. This addition does not change the behaviour in the normal (non-migration) case at all, and at migration, it just makes sure that we do not prematurely kill the old baker (which might still be needed).

• green CI
• tezt-cloud scenarios

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