Bound level of attested importable slots for rollups

What

Currently (before this MR), an attested slot could be imported by any kernel (honest or not) at any level. For instance, a DAL slot attested 10 years ago could still be imported (or) not by a rollup.

So, in this MR, we introduce a kind of TTL for attested slots: once the TTL is over, all kernels that would attempt to import a page of that slot should get None (or the empty page, depending on the encoding).

As a remark, note that the issue here is not that the slots was attested 10 years ago. We could have situations where the slot was attested and imported by a rollup 10 years ago, but the commitment (and refutation game) only starts now. The issue is rather to bound the amount of cells one should remember to play refutation games.

Why

We introduce this TTL because, to be able to still play refutation games if needed, rollups operators should keep all the history of the skip list (different cells). This validity window (fixed in this MR to 241920, corresponding to 28 days with a block time of 10 seconds) allows bounding the size of the skip list history cache we sould retain: we only need the ~ max number of slots x 241920 last cells of the skip list to produce refutation proofs with the facilities offered by Dal_slot_repr. For older cells/slots, we automatically know that the slots are not attested (anymore).

How

A constant dal_attested_slots_validity_lag is introduced for that purpose. The function Sc_rollup_proof_repr.Dal_helpers.valid_slot_id is extended with dal_attested_slots_validity_lag to take the new semantics into account. This function is used both to decide if there is something to possibly import, given a slot_id, or not; and to decide if a Dal_slot_repr.History.proof needs to be generated or not.

Manually testing the MR

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