DAL_node: Protocol change for attestable_slots RPC

What

Closes #4612 (closed).

Why

The current code from get_attestable_slots (the code behind the GET RPC for attestable_slots) currently does not expect the attestation_lag value to change at all, therefore it is not ready for such a change. However, this change would ultimately be introduced by the Reduce DAL latency project.

In the code, we currently associate the following mapping:

attested_level = published_level + attestation_lag

And the attestation_lag is obtained from Last_proto. Therefore, if we lower this lag (say from 8 to 6), we will have a dilemma for levels M+6 and M+7 (where M is the migration level): which published level to choose? Indeed, for M+6 attested level we can have M-2 as published level (with lag = 8) and M as published level (with lag = 6). Additionally, for attested levels from M to M+5, if we use the new lag (6) to calculate the corresponding published levels, we get levels from the old protocol, which does not seem right.

How

Our solution is to ignore the published slots corresponding to attested_levelss from levels M to M + new_lag - 1, because those ones have corresponding published levels from the old protocol. Subsequently, the levels from M + new_lag forward will have corresponding published levels new_lag levels behind (which is still in the new protocol). And also, consequently, the published_levels from M - old_lag to M - 1 (i.e. last old_lag blocks of the old protocol) will not get attested, as intented.

This was discussed in the following Slack thread, and is still subject to change, should the team agree.

Manually testing the MR

CI green

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